[SLOF] [PATCH 0/5] Fix stack overflow problem when using many USB devices
david at gibson.dropbear.id.au
Thu Nov 26 11:48:30 AEDT 2015
On Wed, Nov 25, 2015 at 08:58:14PM +0100, Thomas Huth wrote:
> Current version of SLOF has a stack overflow problem that
> can be triggered by using a lot of USB devices, for example with:
> qemu-system-ppc64 -nographic -vga none -device pci-ohci,id=ohci0 \
> `for ((i=0;i<38;i++)); do echo -n "-device usb-mouse " ; done`
> When using so many USB devices, QEMU builds a tree of USB hubs to
> connect them. When the USB scan walks this tree, there is a
> recursion via the engine() function (in slof/paflof.c):
> Forth code from dev-hub.fs calls usb_hub_init(), which calls
> setup_new_device(), which then calls slof_usb_handle() to execute
> Forth code for the next device via engine(). If that next device
> is a hub, we end up recursively in dev-hub.fs again.
> That's theoretically fine, but currently the engine() function
> has a very huge stack frame (more than 3000 bytes if I measured
> it right), so we quickly overflow the system stack (which is
> currently defined as 8k bytes in entry.S).
> There are two major culprits for this heavy stack usage: libnvram
> and the FAST_RFILL macro, which are both using large arrays
> in the Forth-to-C glue code (that gets included into the engine()
> function). This patch series fixes these problems by moving the
> code with the arrays to separate C functions instead, so that the
> arrays only temporarily occupy the stack instead of blocking the
> longer-lasting stack frames of the engine() function.
> Beside these two major fixes, the first patch also introduces
> a simple check for stack overlow in engine(), so that such
> problems are easier to detect and debug in the future.
> The second patch saves some additional bytes in libusb, which
> is neglectable compared to libnvram and FAST_RFILL, but I
> noticed this first, before finding the other two, so I've
> included this patch, too.
> All in all, stack usage in paflof is now down from more than
> 16kB to ca. 6kB when the USB bus is fully populated.
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1261288
I don't know SLOF well enough to review the code effectively, but this
all sounds like a good idea from a conceptual point of view.
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the SLOF