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

Hi Nick,

On Mon, Oct 1, 2018 at 10:23 AM Nicholas Piggin [off-list ref] wrote:

On Mon, 1 Oct 2018 09:11:04 +0800
Bin Meng [off-list ref] wrote:

quoted

Hi Nick,

On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin [off-list ref] wrote:

quoted

On Sat, 29 Sep 2018 23:25:20 -0700
Bin Meng [off-list ref] wrote:

quoted

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)?

Regards,
Bin