[PATCH v2 0/2] Allow configurable stack size (especially 32k on PPC64)

[Hamish Martin]

On 02/24/2017 10:54 PM, David Laight wrote:
> From: Hamish Martin
>> Sent: 24 February 2017 00:52
>> This patch series adds the ability to configure the THREAD_SHIFT value and
>> thereby alter the stack size on powerpc systems. We are particularly interested
>> in configuring for a 32k stack on PPC64.
>>
>> Using an NXP T2081 (e6500 PPC64 cores) we are observing stack overflows as a
>> result of applying a DTS overlay containing some I2C devices. Our scenario is
>> an ethernet switch chassis with plug-in cards. The I2C is driven from the T2081
>> through a PCA9548 mux on the main board. When we detect insertion of the plugin
>> card we schedule work for a call to of_overlay_create() to install a DTS
>> overlay for the plugin board. This DTS overlay contains a further PCA9548 mux
>> with more devices hanging off it including a PCA9539 GPIO expander. The
>> ultimate installed I2C tree is:
>>
>> T2081 --- PCA9548 MUX --- PCA9548 MUX --- PCA9539 GPIO Expander
>>
>> When we install the overlay the devices described in the overlay are probed and
>> we see a large number of stack frames used as a result. If this is coupled with
>> an interrupt happening that requires moderate to high stack use we observe
>> stack corruption. Here is an example long stack (from a 4.10-rc8 kernel) that
>> does not show corruption but does demonstrate the length and frame sizes
>> involved.
> ...
>
> ISTM that the device probe needs to be iterative rather than recursive so
> that deeply nested buses don't require deep stacks.
>
> Switching stacks on interrupt entry would also make it much less likely that
> you'll get an unexpected stack corruption.
>
> The problem with just doubling the stack size is that code will just eat
> it all up and, in a few years, something will hit the limit again.
>
> 	David
>
>
Thanks for your comments David.

Yes, restructuring bus/device probing would be a better solution in the 
longer term. It's what Ben H was alluding to in his reply to v1 of this 
patch series. I do suspect that would be a fairly large undertaking 
across the kernel drivers that may expose numerous bugs.

However, I still feel this series has validity given the inequity 
between PPC64 and PPC32 minimum stack frame overhead.
Flipping it on its head, would anyone even consider a patch that sought 
to make things more equivalent between PPC32 and PPC64 where the patch 
involved reducing the PPC32 stack from 8k to something like 6k? I think not.

And of course, finally, this is user selectable and we don't seek to 
modify the current default behaviour.

Cheers,
Hamish M.