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

Nicholas Piggin npiggin at gmail.com
Tue Oct 2 10:03:51 AEST 2018


On Mon, 1 Oct 2018 20:41:19 +0800
Bin Meng <bmeng.cn at gmail.com> wrote:

> Hi Nick,
> 
> On Mon, Oct 1, 2018 at 10:23 AM Nicholas Piggin <npiggin at gmail.com> wrote:
> >
> > On Mon, 1 Oct 2018 09:11:04 +0800
> > Bin Meng <bmeng.cn at gmail.com> wrote:
> >  
> > > Hi Nick,
> > >
> > > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin at gmail.com> wrote:  
> > > >
> > > > On Sat, 29 Sep 2018 23:25:20 -0700
> > > > Bin Meng <bmeng.cn at 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.
> >
> > static inline bool
> > offset_below_red_zone_p (HOST_WIDE_INT offset)
> > {
> >   return offset < (DEFAULT_ABI == ABI_V4
> >                    ? 0
> >                    : TARGET_32BIT ? -220 : -288);
> > }
> >
> > llvm does as well AFAIKS
> >
> >   // DarwinABI has a 224-byte red zone. PPC32 SVR4ABI(Non-DarwinABI) has no
> >   // red zone and PPC64 SVR4ABI has a 288-byte red zone.
> >   unsigned  getRedZoneSize() const {
> >     return isDarwinABI() ? 224 : (isPPC64() ? 288 : 0);
> >   }
> >
> > So I suspect we can get away with using 288 for the kernel. Although
> > the ELFv2 ABI allows 512, I suspect at this point compilers won't switch
> > over without an explicit red zone size flag.
> >  
> 
> Thanks for the info of gcc/llvm codes. I suspect for the red zone size
> gcc/llvm still uses ABIv1 defined value which is 288. If we get way
> with kernel using 288, what's the point of having user as 512 (commit
> 573ebfa6601f)?

See Segher's reply -- they are two different things here. 288 bytes is
the red zone that compilers may use. But there is another region out to
512 bytes which can be used by other system code (not compilers). So
the kernel always has to assume 512 for user.

The kernel code itself knows that it does not use any red zone beyond
288 bytes, so it does not have to preserve any more for its own stack.

Thanks,
Nick


More information about the Linuxppc-dev mailing list