This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] aarch64: Increase MINSIGSTKSZ and SIGSTKSZ
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, Andreas Schwab <schwab at suse dot de>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 02 Apr 2015 17:06:14 +0100
- Subject: Re: [PATCH] aarch64: Increase MINSIGSTKSZ and SIGSTKSZ
- Authentication-results: sourceware.org; auth=none
- References: <mvmwq1v2aqw dot fsf at hawking dot suse dot de> <CAFqB+PzmEF0Mu7pRkoDJ4g6r7o-fqkzMX6STMpZjxBnp2E5tgg at mail dot gmail dot com> <551D19A3 dot 40307 at arm dot com> <20150402155116 dot GY6817 at brightrain dot aerifal dot cx>
On 02/04/15 16:51, Rich Felker wrote:
> On Thu, Apr 02, 2015 at 11:27:47AM +0100, Szabolcs Nagy wrote:
>> 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.
>>
>> 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)
>
> The big detail to notice here is symbol relocation. If you do lazy
> bindings, the resolver function needs space to backup any registers
> that might ever be used as argument registers in case a
> not-yet-resolved function is called from the signal handler. On an
> implementation without lazy bindings, 6k (like we have on musl now) or
> maybe even 5k is a suitable value for the minimum, but on glibc you
> probably need at least 7k and maybe more, so 8k sounds like a good
> choice to me.
>
this is already committed, but i wonder what others think about
the two interpretations: only account for kernel saved context
needed for signal deliver vs. kernel context + worst case libc
overhead.
(i'd say this should be reported to the austingroup for clarification,
but i don't see any simple way to specify the stack requirements on
the c language level)
i think even with the 'kernel context only' definition there might
be a reason for different kernel vs libc limit because of cpu
extensions that the libc abi cares about but the installed kernel
may not. (so not checking the size in sigaltstack is observably
non-conforming).