From mboxrd@z Thu Jan 1 00:00:00 1970 From: szabolcs.nagy@arm.com (Szabolcs Nagy) Date: Mon, 12 Sep 2016 17:44:48 +0100 Subject: [RFC PATCH 0/5] arm64: Signal context expansion In-Reply-To: <20160912153015.GD3958@e103592.cambridge.arm.com> References: <1473430576-20792-1-git-send-email-Dave.Martin@arm.com> <20160909152047.GA3958@e103592.cambridge.arm.com> <20160912111749.GB3958@e103592.cambridge.arm.com> <57D6C33D.9020003@arm.com> <20160912153015.GD3958@e103592.cambridge.arm.com> Message-ID: <57D6DB80.4090105@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 >