RFC arm64: Signal context expansion
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 5 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 5 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/5] arm64: Signal context expansion
Quoted 39 lines · Dave Martin
Quoted 1 line · Szabolcs Nagy
On 12/09/16 12:17, Dave Martin wrote:
[...]
Quoted 1 line
Quoted 1 line
Quoted 1 line · Dave Martin
[...]
Quoted 27 lines
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
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.
Quoted 9 lines
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 passesss_size= MINSIGSTKSZ, and is built against glibc<2.22 [1], [2], running on linux>=4.3 [3], which is an ABI break in case wheresigaltstack()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).
Quoted 2 lines
i assume the kernel can avoid saving SVE regs when they are not used by the process.
Quoted 9 lines
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.
Quoted 10 lines
Quoted 10 lines
Quoted 6 lines
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.
Quoted 7 lines
Quoted 2 lines
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.)
Quoted 9 lines
Quoted 6 lines
fortunately glibc
PTHREAD_STACK_MINis 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.)
Quoted 5 lines
[...]
Cheers
---Dave