From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D8566C531DC for ; Fri, 23 Aug 2024 11:48:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AEj9eZnQqrPpKXTVjssY4iVspjWviRDHQvCh/yugp3M=; b=nRkSxyHIrzEewkRSGvcNcN7YHA qtAsiaXGJFeaPzX6cPoCfDpxQtpSej/nEk2e8TtUAACTHg5t+P7OrSxQfJtBsyj0dqHznecjWL1qB su0VZxIQf2PENpwcgvI9o8T7B62WqxmArUJD1Z9zyk5lasJC/WZTyoFw673rEqPW8joiw6Wa7ldP8 RTLyofOwA59t4N9qcMuogwKX1FU7qtA5xrQayUfsykpqobdWPRvsEjkcHhssrQb8Fjc//kAPkSlcH IkOMpgP7eRGFFnqBnc70DYCHimo09PJq+Kkuxrbc0VzEYoYnYTTTyCePKXrOhsp3Z2QnpRztxxTy0 SieQMnqw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1shSlo-0000000GZuB-1ayD; Fri, 23 Aug 2024 11:47:56 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1shSk8-0000000GZfu-3klT for linux-arm-kernel@lists.infradead.org; Fri, 23 Aug 2024 11:46:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 2DE04CE1065; Fri, 23 Aug 2024 11:46:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4404DC32786; Fri, 23 Aug 2024 11:46:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724413570; bh=R83r/nnDkz05K1PZMSgl1NSInycanGr9TY9jMsvNkAQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LIq8y8aWpCk5Zp/rJoL9BLYRZxKkr2dopgMriIb1TepmW+mOIa4e9tN791vn4/KMC 06Sghk+HO9JqXftmiL3Xl/Rzx7faoYevAndhRqsFAoxKwvbZujiqlgXAUoBI+idiGH ehhKVRg5y6FYMCVvNGbWgag71dbtsfL709ubqKXaWUpJC7uSMwcf2kFe3Y0kHvifI5 kia2J9D3QDdAV1T/py+iu9syXpuNvNHpqfK+0AP0tiBK+TTVy7+FDsD94hhQ1NIVdL w8RWrxT6g03Yhgy8JUhNTU+ubptTm5G50yz0C4jZFVq3MPOWIM2PM6EuyQ6E/c+MLC 1VFy9hUcAS0QQ== Date: Fri, 23 Aug 2024 12:46:05 +0100 From: Will Deacon To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Mark Brown , Joey Gouly Subject: Re: [PATCH] arm64: signal: Update sigcontext reservations table Message-ID: <20240823114602.GA32020@willie-the-truck> References: <20240729144149.249096-1-Dave.Martin@arm.com> <20240820133739.GA28338@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240823_044613_309751_26B5D184 X-CRM114-Status: GOOD ( 37.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 20, 2024 at 03:38:34PM +0100, Dave Martin wrote: > On Tue, Aug 20, 2024 at 02:37:40PM +0100, Will Deacon wrote: > > On Mon, Jul 29, 2024 at 03:41:49PM +0100, Dave Martin wrote: > > > The table tracking space usage in sigcontext.__reserved[] has got > > > a bit out of date. > > > > > > Update it, and clarify the opt-in constraints. > > > > > > Note, svl <= 64 would be a sufficient condition for keeping the > > > sve_context within range when in streaming SVE mode under SME, but > > > then za_context gets too big and userspace loses anyway. To keep > > > the conditions simple, just write "svl <= 32" everywhere. > > > > > > No functional change. > > > > > > Signed-off-by: Dave Martin > > > > > > --- > > > > > > Note, this is a back-of-the-envelope calculation... but whatever way I > > > slice it, __reserved[] looks pretty much full (!) > > > > > > If Mark in particular can double-check the SME impact, that would be > > > appreciated. > > > > > > New arch features with a non-trivial amount of state that needs to be > > > saved may need to be disabled by default and require explicitly turning > > > on by a syscall unless we want to allow some ABI breakage (x86's > > > experience suggests that the world takes a long time to explode when > > > signal frames outgrow their official size, though). > > > > > > Either way, do we need a new strategy to slow down the filling of the > > > remaining space? There is continuing demand on it (see e.g., [1]). > > > > > > Migration note: at least glibc since version 2.34 [2] has stopped > > > offering compile-time constant signal stack size #defines to programs > > > built with -D_GNU_SOURCE. [3] This should mitigate ABI breaks for > > > programs that bother to size stacks correctly. > > > > > > I haven't checked what other libcs and runtimes are doing. > > > > > > Additional SME note: since userspace can freely switch in and out of > > > streaming SVE mode and freely enable/disable ZA and ZT0, I'm assuming > > > that none of sve_context, za_context and zt_context are mutually > > > exclusive, but please shout if I have confused myself here. > > > > > > [1] [PATCH v4 18/29] arm64: add POE signal support > > > https://lore.kernel.org/linux-arm-kernel/20240503130147.1154804-19-joey.gouly@arm.com/ > > > > > > [2] [glibc] glibc-2.34 > > > https://sourceware.org/git/?p=glibc.git;a=tag;h=9df03063320651bc629fa427eef3ac73fabb61ba > > > > > > [3] [glibc] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] > > > https://sourceware.org/git/?p=glibc.git;a=commit;f=sysdeps/unix/sysv/linux/bits/sigstksz.h;h=6c57d320484988e87e446e2e60ce42816bf51d53 > > > --- > > > arch/arm64/include/uapi/asm/sigcontext.h | 11 +++++++++-- > > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h > > > index 8a45b7a411e0..2cd60fd64e9a 100644 > > > --- a/arch/arm64/include/uapi/asm/sigcontext.h > > > +++ b/arch/arm64/include/uapi/asm/sigcontext.h > > > @@ -44,11 +44,18 @@ struct sigcontext { > > > * > > > * 0x210 fpsimd_context > > > * 0x10 esr_context > > > - * 0x8a0 sve_context (vl <= 64) (optional) > > > + * 0x8a0 sve_context (vl <= 64 && svl <= 32) (optional) > > > + * 0x10 tpidr2_context (optional) > > > + * 0x410 za_context (svl <= 32) (optional) > > > + * 0x50 zt_context (optional) > > > + * 0x10 fpmr_context (optional) > > > * 0x20 extra_context (optional) > > > * 0x10 terminator (null _aarch64_ctx) > > > * > > > - * 0x510 (reserved for future allocation) > > > + * 0x90 (reserved for future allocation) > > > + * > > > + * where vl is the non-streaming SVE vector length, as set with PR_SVE_SET_VL, > > > + * and svl is the streaming SVE vector length, as set with PR_SME_SET_VL. > > > > These are quite fiddly to check by hand, but the ones I *did* check > > appear to be correct. The discussion with Mark seems tangential to the > > actual diff, so I'm inclined to apply this if nobody objects. > > > > Will > > I'm wondering whether we should just get rid of this instead, since > it's not that maintainable: see [4]. I suppose we could, but I must confess that I find this comment a lot easier to digest that the fiddly maze of inconsistent macros we have for the different contexts. Then again, all that really matters, I suppose, is that we don't accidentally over-allocate the maximum size of the sigcontext. That ought to be enforceable. Will