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

[Dave Martin]

On Mon, Sep 12, 2016 at 05:44:48PM +0100, Szabolcs Nagy wrote:
> 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.

Well, indeed.

In an ideal world, we also like to be able to make use of new features
though.

> >>
> >>>
> >>> 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.)

"Requires some specific, nonstandard libc" = "not portable".

I don't say that this isn't a good feature of musl libc, just that this
feature is not generally available.

> 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.)

Unfortunately, that is true.  Any component (including libc) that makes
assumptions about the kernel signal stack overhead may break.

(Whether musl should have invented its own magic number for MINSIGSTKSZ
instead of adding its own known overhead to the kernel's MINSIGSTKSZ is
debatable, but in this case it is lucky that it did.)

> >> 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.)

So, increasing MINSIGSTKSZ doesn't look a great idea, partly because it
breaks stuff, and partly because there is no correct value to change it
to -- we may have to make the same break all over again, at some point
in the future, or set it to something ridiculously large.


I think it's clear that this series needs to honor (and refuse to
overrun) the alternate signal stack size down to the "legacy"
MINSIGSTKSZ (5K).

But how to ensure that software that was built "too small" a MINSIGSTKSZ
for all arch extensions known to the running kernel is a separate
problem that needs careful thought and libc involvement.

Cheers
---Dave