public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel•crashing.org>
To: Nicholas Piggin <npiggin@gmail•com>
Cc: linuxppc-dev <linuxppc-dev@lists•ozlabs.org>
Subject: Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes
Date: Tue, 2 Oct 2018 03:30:19 -0500	[thread overview]
Message-ID: <20181002083018.GH23155@gate.crashing.org> (raw)
In-Reply-To: <20181002095929.25253b99@roar.ozlabs.ibm.com>

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@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

  reply	other threads:[~2018-10-02  8:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-30  6:25 [PATCH 1/2] powerpc/64: Remove duplicated -mabi=elfv2 for little endian targets Bin Meng
2018-09-30  6:25 ` [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes Bin Meng
2018-09-30 23:27   ` Nicholas Piggin
2018-10-01  1:11     ` Bin Meng
2018-10-01  2:22       ` Nicholas Piggin
2018-10-01  8:51         ` Segher Boessenkool
2018-10-01 23:59           ` Nicholas Piggin
2018-10-02  8:30             ` Segher Boessenkool [this message]
2018-10-01 12:41         ` Bin Meng
2018-10-02  0:03           ` Nicholas Piggin
2018-10-01  9:07   ` Segher Boessenkool
2018-10-01  8:59 ` [PATCH 1/2] powerpc/64: Remove duplicated -mabi=elfv2 for little endian targets Segher Boessenkool
2018-10-01 12:19   ` Bin Meng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181002083018.GH23155@gate.crashing.org \
    --to=segher@kernel$(echo .)crashing.org \
    --cc=linuxppc-dev@lists$(echo .)ozlabs.org \
    --cc=npiggin@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox