[PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Segher Boessenkool]

On Tue, Oct 02, 2018 at 09:59:29AM +1000, Nicholas Piggin wrote:
> On Mon, 1 Oct 2018 03:51:21 -0500
> Segher Boessenkool <segher at kernel.crashing.org> wrote:
> > And that is required by the ABI!
> > 
> > """
> > 2.2.2.4. Protected Zone
> > 
> > The 288 bytes below the stack pointer are available as volatile program
> > storage that is not preserved across function calls. Interrupt handlers and
> > any other functions that might run without an explicit call must take care
> > to preserve a protected zone, also referred to as the red zone, of 512 bytes
> > that consists of:
> > 
> >  * The 288-byte volatile program storage region that is used to hold saved
> >    registers and local variables
> >  * An additional 224 bytes below the volatile program storage region that is
> >    set aside as a volatile system storage region for system functions
> > 
> > If a function does not call other functions and does not need more stack
> > space than is available in the volatile program storage region (that is, 288
> > bytes), it does not need to have a stack frame. The 224-byte volatile system
> > storage region is not available to compilers for allocation to saved
> > registers and local variables.
> > """
> > 
> > A routine has a red zone of 288 bytes.  Below there is 224 more bytes of
> > available storage, but that is not available to the routine itself: some
> > (asynchronous) other code (like an interrupt) can use (i.e. clobber) it.
> 
> Thanks Segher, that explains it very well and shows we are safe with
> 288 in the kernel. So we can leave the code as-is, but the comment
> could be updated.
> 
> What are "system functions" exactly?

That is an excellent question.  I think it was left vague on purpose?
"Stuff a user program cannot do itself", "ABI stuff", "whatever the OS
defines as system stuff"?

> Can the kernel use that, or are
> we talking about user mode system code like libraries? The kernel
> could maybe use that for scratch space for synchronous interrupts to
> avoid using a slow SPR for scratch.

If you're already using the kernel stack, sure.  When does this happen?


Segher