From: Nicholas Piggin <npiggin@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
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 09:59:29 +1000 [thread overview]
Message-ID: <20181002095929.25253b99@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20181001085121.GB23155@gate.crashing.org>
On Mon, 1 Oct 2018 03:51:21 -0500
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> Hi!
>
> On Mon, Oct 01, 2018 at 12:22:56PM +1000, Nicholas Piggin wrote:
> > On Mon, 1 Oct 2018 09:11:04 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> > > > On Sat, 29 Sep 2018 23:25:20 -0700
> > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit
> > > > > userspace to 512 bytes") only changes stack userspace redzone size.
> > > > > We need increase the kernel one to 512 bytes too per ABIv2 spec.
> > > >
> > > > You're right we need 512 to be compatible with ABIv2, but as the
> > > > comment says, gcc limits this to 288 bytes so that's what is used
> > > > to save stack space. We can use a compiler version test to change
> > > > this if llvm or a new version of gcc does something different.
> > > >
> > >
> > > I believe what the comment says is for ABIv1. At the time when commit
> > > 573ebfa6601f was submitted, kernel had not switched to ABIv2 build
> > > yet.
> >
> > I see, yes you are right about that. However gcc still seems to be using
> > 288 bytes.
>
> 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? 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.
Thanks,
Nick
>
>
> Segher
next prev parent reply other threads:[~2018-10-02 0:01 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 [this message]
2018-10-02 8:30 ` Segher Boessenkool
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=20181002095929.25253b99@roar.ozlabs.ibm.com \
--to=npiggin@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).