Re: [musl] [PATCH] fix MINSIGSTKSZ and SIGSTKSZ for powerpc64

[Rich Felker <dalias@libc.org>]

On Thu, Aug 29, 2024 at 05:38:42AM +0200, psykose wrote:
> since kernel commit 2f82ec19757f58549467db568c56e7dfff8af283
> (https://github.com/torvalds/linux/commit/2f82ec19757f58549467db568c56e7dfff8af283)
> the kernel has updated these minimum values. having these small values breaks
> sysconf(_SC_MINSIGSTKSZ) too; it returns 4224 in musl currently which ends up
> returning ENOMEM from the syscall made in sigaltstack.
> 
> raising these to match the kernel fixes sigaltstack use on powerpc64(le).
> caught by glib's 2.82 testsuite

I don't follow how you're claiming sysconf(_SC_MINSIGSTKSZ) is broken.
It will just return the kernel-provided value on new kernels that
insist on having a larger stack. In particular I don't see where the
value 4224 is supposed to be coming from. If there's something I'm
missing, please explain.

Changing the macros is ABI breakage, perhaps minor, but still not
nice. My leaning if any change is made would be to remove them, but
unfortunately the Austin Group didn't seem to have gotten the sysconf
stuff (and making these macros optional) into Issue 8, so they're
still mandatory. So I'm not sure what is best to do. Ultimately, due
to kernel bad behavior ignoring the "don't break userspace" rule and
ignoring POSIX, we're in a situation where the macros are required but
necessarily don't actually work, and the only way to make a reliably
working application is to use the not-yet-standard sysconf() lookups
instead.

Regardless of how MINSIGSTKSZ is handled, increasing SIGSTKSZ from 10k
to 32k makes no sense. At most it needs to be increased by the
increase in MINSIGSTKSZ, or perhaps twice that if the goal is to allow
for 2 signal frames (but we currently don't do that in sysconf, so if
that's desirable it should be proposed as its own thing not a
special-case jacking up of the value for one arch).

Rich