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 68F35C52D6F for ; Tue, 6 Aug 2024 10:37:11 +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=Ye+9Ag7tDvOVMpDEWHEOtpect0YBIdwBXy2JXDaOl0g=; b=rzRjVpYpTENRw7Ja/zXqnqAlQK eot7QTAshPSA6LNyufDaS1DrbsFWSoZQ7UthvPmIx7sSYCT8jnQrRxmEW4kaTb66HAQ71bvRL35iM UcRb18rVr7Osj5Lg2PEZnHW6rmawPECMlsG1LR/jp+1X0zYK365XSo1CHCJ0ED5fAdvPN6gEDBUOX yOHXV8aP7w1SsExtBZXBJP63XcxJAFAj3rVpVlCnZxgIrWRewhQ3wgrd1GBTCdk6k+gEdMiyLFXT+ 5JweCGcCrvmcXB1Qr7pzpyIWwmsvJowmiyKd8gD3mbG8fBHPzW2RqRNsJ09UBmg7Qy8dCsbH7Xyfa QdXmGYUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbHYp-00000001Ebd-2pzA; Tue, 06 Aug 2024 10:36:59 +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 1sbHYI-00000001EXv-3glz for linux-arm-kernel@lists.infradead.org; Tue, 06 Aug 2024 10:36:28 +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 BE013FEC; Tue, 6 Aug 2024 03:36:51 -0700 (PDT) Received: from e124191.cambridge.arm.com (e124191.cambridge.arm.com [10.1.197.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7792B3F6A8; Tue, 6 Aug 2024 03:36:22 -0700 (PDT) Date: Tue, 6 Aug 2024 11:35:32 +0100 From: Joey Gouly To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, aneesh.kumar@kernel.org, aneesh.kumar@linux.ibm.com, bp@alien8.de, broonie@kernel.org, catalin.marinas@arm.com, christophe.leroy@csgroup.eu, dave.hansen@linux.intel.com, hpa@zytor.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, maz@kernel.org, mingo@redhat.com, mpe@ellerman.id.au, naveen.n.rao@linux.ibm.com, npiggin@gmail.com, oliver.upton@linux.dev, shuah@kernel.org, szabolcs.nagy@arm.com, tglx@linutronix.de, will@kernel.org, x86@kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 18/29] arm64: add POE signal support Message-ID: <20240806103532.GA1986436@e124191.cambridge.arm.com> References: <20240503130147.1154804-1-joey.gouly@arm.com> <20240503130147.1154804-19-joey.gouly@arm.com> <20240801155441.GB841837@e124191.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240806_033627_032737_822B28D3 X-CRM114-Status: GOOD ( 37.95 ) 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 Thu, Aug 01, 2024 at 05:22:45PM +0100, Dave Martin wrote: > On Thu, Aug 01, 2024 at 04:54:41PM +0100, Joey Gouly wrote: > > On Thu, Jul 25, 2024 at 05:00:18PM +0100, Dave Martin wrote: > > > Hi, > > > > > > On Fri, May 03, 2024 at 02:01:36PM +0100, Joey Gouly wrote: > > > > Add PKEY support to signals, by saving and restoring POR_EL0 from the stackframe. > > > > > > > > Signed-off-by: Joey Gouly > > > > Cc: Catalin Marinas > > > > Cc: Will Deacon > > > > Reviewed-by: Mark Brown > > > > Acked-by: Szabolcs Nagy > > > > --- > > > > arch/arm64/include/uapi/asm/sigcontext.h | 7 ++++ > > > > arch/arm64/kernel/signal.c | 52 ++++++++++++++++++++++++ > > > > 2 files changed, 59 insertions(+) > > > > > > > > diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h > > > > index 8a45b7a411e0..e4cba8a6c9a2 100644 > > > > --- a/arch/arm64/include/uapi/asm/sigcontext.h > > > > +++ b/arch/arm64/include/uapi/asm/sigcontext.h > > > > > > [...] > > > > > > > @@ -980,6 +1013,13 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user, > > > > return err; > > > > } > > > > > > > > + if (system_supports_poe()) { > > > > + err = sigframe_alloc(user, &user->poe_offset, > > > > + sizeof(struct poe_context)); > > > > + if (err) > > > > + return err; > > > > + } > > > > + > > > > return sigframe_alloc_end(user); > > > > } > > > > > > > > @@ -1020,6 +1060,15 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user, > > > > __put_user_error(current->thread.fault_code, &esr_ctx->esr, err); > > > > } > > > > > > > > + if (system_supports_poe() && err == 0 && user->poe_offset) { > > > > + struct poe_context __user *poe_ctx = > > > > + apply_user_offset(user, user->poe_offset); > > > > + > > > > + __put_user_error(POE_MAGIC, &poe_ctx->head.magic, err); > > > > + __put_user_error(sizeof(*poe_ctx), &poe_ctx->head.size, err); > > > > + __put_user_error(read_sysreg_s(SYS_POR_EL0), &poe_ctx->por_el0, err); > > > > + } > > > > + > > > > > > Does the AArch64 procedure call standard say anything about whether > > > POR_EL0 is caller-saved? > > > > I asked about this, and it doesn't say anything and they don't plan on it, > > since it's very application specific. > > Right. I think that confirms that we don't absolutely need to preserve > POR_EL0, because if compiler-generated code was allowed to fiddle with > this and not clean up after itself, the PCS would have to document this. > > > > > > > > > > > > > In theory we could skip saving this register if it is already > > > POR_EL0_INIT (which it often will be), and if the signal handler is not > > > supposed to modify and leave the modified value in the register when > > > returning. > > > > > > The complexity of the additional check my be a bit pointless though, > > > and the the handler might theoretically want to change the interrupted > > > code's POR_EL0 explicitly, which would be complicated if POE_MAGIC is > > > sometimes there and sometimes not. > > > > > > > > > > > I think trying to skip/optimise something here would be more effort than any > > possible benefits! > > Actually, having thought about this some more I think that only dumping > this register if != POR_EL0_INIT may be right right thing to do. > > This would mean that old binary would stacks never see poe_context in > the signal frame, and so will never experience unexpected stack > overruns (at least, not due solely to the presence of this feature). They can already see things they don't expect, like FPMR that was added recently. > > POE-aware signal handlers have to do something fiddly and nonportable > to obtain the original value of POR_EL0 regardless, so requiring them > do handle both cases (present in sigframe and absent) doesn't seem too > onerous to me. If the signal handler wanted to modify the value, from the default, wouldn't it need to mess around with the sig context stuff, to allocate some space for POR_EL0, such that the kernel would restore it properly? (If that's even possible). > > > Do you think this approach would break any known use cases? Not sure. > > Cheers > ---Dave >