Re: [PATCH] aarch64: Increase MINSIGSTKSZ and SIGSTKSZ

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 02/04/15 10:59, Marcus Shawcroft wrote:
> On 2 April 2015 at 09:30, Andreas Schwab <schwab@suse.de> wrote:
>>         [BZ #16850]
>>         * sysdeps/unix/sysv/linux/aarch64/bits/sigstack.h: New file.
>> ---
>>  sysdeps/unix/sysv/linux/aarch64/bits/sigstack.h | 54 +++++++++++++++++++++++++
>>  1 file changed, 54 insertions(+)
>>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/bits/sigstack.h
> 
> Hi.
> 
> Back in November,
> https://sourceware.org/ml/libc-alpha/2014-11/msg00339.html, RenLin
> proposed 8k for MINSTKSZ, a few days ago, off list, Szabolcs suggest
> 6k.  The ucontext is 4560 bytes and my understanding is that MINSTKSZ
> only needs to be sufficient for the kernel to deliver the signal frame
> which suggests that your proposed 5k is sufficient.
> 
> OK
> 
> /Marcus
> 


the 5K min is enough for signal delivery by the kernel

but the way i read the standard, applications are expected to allocate
MINSIGSTKSZ + their own usage and it seems to be a stretch to
include all libc overhead, such as symbol relocation, in "own usage"
(historically the min size is small on many archs so probably it's
not an issue in practice)

note that having a huge difference between min and default does not
help: portable applications cannot expect large space above min
because most archs use min+6K for default stack size.
(so with 5K min i'd use 12K default, but this is just bikesheding)


(i note here that there is a glibc conformance bug in sigaltstack:
it does not check that the provided stack size is >= MINSIGSTKSZ
and relies on the kernel side doing the check which is broken
on every arch where the kernel has different limit

with my interpretation of MINSIGSTKSZ different kernel side
limit makes perfect sense

this bug is convenient now, because it means we can increase
the limit without affecting existing binaries, but i think it
should be fixed eventually)