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 C3744C3DA4A for ; Tue, 20 Aug 2024 14:48:20 +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=tPGCwytVtAdEAPk8OWqm1zF6E82U6FGQO5cHBr1CsGs=; b=xdVdeY+zeDdLprbSp3Az0fFTUx /ZfIZXLRVaJCVliRAgPDd5Sb+UaP3yI3AHXeYBAogrFhEBOKFdYQXKKKMnC76lr6eGeazzsiDQxiO lQrMv52UMIDRSSBr5f3CyGgE9KsIJuvjda5Iij6t+QjBX4GbhV2V8H5bTueNxF8EdzKtjT1C42R8t R7xPvQ20t/HtL5zrLF+A35KGadUi4aV7YRjLSz0wSANiiNWUDvOT5ugPCsJ6EhBpPQ1gXLyB0BQUg d0yWqOe5u8oigIuNySUIMXNNH5ttK8Nd4031Ft/qSZHJyPnXSIY0wBDuoPcGyM3iN+x5ozran+1hQ 0TICMQuw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgQ9a-00000005dYg-1lzt; Tue, 20 Aug 2024 14:48:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgQ0M-00000005ani-0NQ7 for linux-arm-kernel@lists.infradead.org; Tue, 20 Aug 2024 14:38:39 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A6437DA7; Tue, 20 Aug 2024 07:39:03 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B94013F66E; Tue, 20 Aug 2024 07:38:36 -0700 (PDT) Date: Tue, 20 Aug 2024 15:38:34 +0100 From: Dave Martin To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Mark Brown , Joey Gouly Subject: Re: [PATCH] arm64: signal: Update sigcontext reservations table Message-ID: 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: <20240820133739.GA28338@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240820_073838_341468_78CF8940 X-CRM114-Status: GOOD ( 36.38 ) 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 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]. The discussion re POR_EL0 has moved in the direction of probably dumping this register unconditionally. [5] Ideally we wouldn't, but there's no way to know in advance whether POR_EL0 counts as "in use", or to anticipate whether a signal handler might want to alter it. Trapping POR_EL0 until something writes it or a pkey_foo() syscall is called is an option, but this feels like overkill. We could also come up with a way for a signal handler to hang extra stuff off the sigframe to be restored by sigreturn even when there's no space to allocate another record, but again, the complexity does not feel well justified until somebody shouts about it. I can propose something if you think it's worth discussing. Cheers ---Dave [4] https://lore.kernel.org/linux-arm-kernel/Zr4aJqc%2FifRXJQAd@e133380.arm.com/ [5] https://lore.kernel.org/linux-arm-kernel/ZsSgKl2JINjdpuW1@e133380.arm.com/