Re: [RFC PATCH 0/5] arm64: Signal context expansion

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

On 12/09/16 16:30, Dave Martin wrote:
> On Mon, Sep 12, 2016 at 04:01:17PM +0100, Szabolcs Nagy wrote:
>> On 12/09/16 12:17, Dave Martin wrote:
> 
> [...]
> 
>>>> On 09/09/2016 05:21 PM, Dave Martin wrote:
> 
> [...]
> 
>>>>> I wonder whether we should make the signal stack size runtime
>>>>> discoverable through sysconf() instead...
>>>
>>> I will likely suggest this for the future, but of course it doesn't help
>>> for current binaries.
>>>
>>>
>>> Note that MINSIGSTKSZ stared life wrong for arm64, and has since gone
>>> through a few ABI breaking changes.  I don't condone this, but we have
>>> form in this area :/
>>>
>>> sigaltstack() already fails with ENOMEM for software that passes
>>> ss_size = MINSIGSTKSZ, and is built against glibc<2.22 [1], [2], running
>>> on linux>=4.3 [3], which is an ABI break in case where sigaltstack() is
>>> otherwise guaranteed to succeed.
>>>
>>
>> yes, this was abi breaking change.
>>
>> if glibc does not care about existing binaries
>> that use sigaltstack with MINSIGSTKSZ then it can
>> increase the size, but i think the kernel should
>> not change the abi (there are other libcs and libc
>> independent runtime systems on linux for aarch64
>> with their own sigaltstack setup, not all of them
>> may care about SVE).
>>
>> i assume the kernel can avoid saving SVE regs when
>> they are not used by the process.
> 
> I can (and do), in my patches (not posted yet).
> 
> The real issue here is that a recently updated shared library might be
> optimised to use SVE, where the program using it is an older, SVE-
> unaware binary.
> 
> (think of an optimised math library using some new fancy SVE-based
> number crunching internally).
> 

this is why sve would be a new abi in an ideal world,
instead of subtly changing behaviour behind existing
binaries.

>>
>>>
>>> The bottom line here is that the sigaltstack() API is broken with regard
>>> to extensibility, so we cannot extend the amount of signal state without
>>> breaking something.
>>>
>>
>> extending signal state can break things independently
>> of sigaltstack.
>>
>> binaries with strict guarantees about worst case stack
>> usage can change behaviour.
> 
> Indeed, but this is not a new issue.  Software must run with enough
> stack in order to be portable, but there is no portable way to determine
> how much stack is needed.
> 

why not?

musl libc has stack usage guarantee that can be checked
by the compiler that built the libc on all supported
targets. (with some manual checks in a few cases.)

however as soon as targets change the signal frame size
randomly, these worst case guarantees get broken.
(musl's MINSIGSTKSZ was always 6k on aarch64, even
before the kernel changed it.)

>> fortunately glibc PTHREAD_STACK_MIN is huge on aarch64
>> so applications using it are unlikely to break because
>> of the increased signal state.
>> (this also means it's impossible to have threads with
>> tiny stacks on glibc, so large amount of threads means
>> large amount of commit charge.)
> 
> Again, not a new problem.
> 

on musl PTHREAD_STACK_MIN is small, so the sve signal
state can break existing binaries that use tiny thread
stack (there is at least one linux distro that supports
musl+aarch64, although they don't distribute binary
packages yet).

so even if the glibc abi changes, i think the kernel
should not do the change, at least not immediately.

(and if the kernel decides to increase MINSIGSTKSZ
i think it should wait for distros picking up new
enough glibc with increased MINSIGSTKSZ to avoid
spuriously failing sigaltstack calls.)

> [...]
> 
> Cheers
> ---Dave
>