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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1831FC52D6F for ; Tue, 6 Aug 2024 10:36:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 753756B007B; Tue, 6 Aug 2024 06:36:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 703616B0082; Tue, 6 Aug 2024 06:36:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CAB06B0083; Tue, 6 Aug 2024 06:36:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 38ED06B007B for ; Tue, 6 Aug 2024 06:36:29 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DFF9AA094A for ; Tue, 6 Aug 2024 10:36:28 +0000 (UTC) X-FDA: 82421466456.13.81C87F1 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf27.hostedemail.com (Postfix) with ESMTP id F0AFC40002 for ; Tue, 6 Aug 2024 10:36:26 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf27.hostedemail.com: domain of joey.gouly@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=joey.gouly@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722940525; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ye+9Ag7tDvOVMpDEWHEOtpect0YBIdwBXy2JXDaOl0g=; b=8IqDKZeWx9Z4ff6BRJeu7Bi2erNQ1hsTv6XXqQJpWUscBYEegWXz8+U5DWPPHd/Hv1yw24 ZMWchy+VGsjKhO1AxAQVdf/KHrh25EExgvUnhHbggPQ3tuRp1ol+r0ygusNg2fNv14jFT8 d+n9GD0ji6NWZeTU2HclueWsvmf1oEc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722940525; a=rsa-sha256; cv=none; b=Hg7Wgm/LJ6ACzytwI6WtYvo6oIweyVj97a5ZytHmUNLTamHWNLA62wyFari0w7qUdSVhTN fZmiZ232qYE9qWpdepjsge/jUHbywkpOuSO0XF66j7cq5cZUOCZ5jMpkUR3TwHxpGWX+I5 MQHN+meCPv8FtwSGNKB0g68vgg9od44= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf27.hostedemail.com: domain of joey.gouly@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=joey.gouly@arm.com 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-Rspamd-Queue-Id: F0AFC40002 X-Stat-Signature: b4pbhoanzdx7km6dx6xdtmezujk7kc6r X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1722940586-523864 X-HE-Meta: U2FsdGVkX1/beMAX4/n4V0MC3OKkrWrCcQRG23n0p6ncLgPMB8KcddgyJZ4tvEMoeid/h0egUV3GT45ZFJ3nDB1KMZVfg/pF15b3q3Sdk6gpzy6oVZ7A1op4GJ/0JuxXyJpeFoTenaAzvMs9iU6gbom4POmr670AvYMKjlMkhSSyfckkUhibdnQHZYo9Z1n19U9uHQvAJnkLjeqWlym1fvhCQfySYy/mCobLP0vqtxG6RYaiIeE3yeIGEy43fMph815/aDKnMqUsW233nFtKYQq8r31AadqDTb/cKXzBrUZX6etTPKWj+pwKDf00ZQA0LVLNRCLfutG1Zbb220gVwqWz8gcWAHd6nDwmmIysEHOFIt8EWQ6IaSv+KO4sRvhBehS0/dEGK8dFSRg0JT7hPaH1CKlPsCSlhizjO5ydRYqc/ALDCP7jwaqQf/uvU1XsAzorNyzwLhID7+Nourzv/76L6dXfZ6//C8CD2hTIn49JNkFIS2Sp7Z+w79B9FabJ1Q3SVcbJnOjC8HS1rDm3QFXgKYdFSnVCg67RHjsfU1G0IG+iLpqbm3/CV6qVvgRxhTLUxiCKJbBkPaK01a58IUci0pLK9fs8uqwRg9yVFJ6PyXI2up3B2lgsJWsakYIyGhe8RhhQ8z1AqAdFHOx/jPL75CqkSrvfHcz/gnqQldMn5QiUMR3nmtWjkaJrivHOMFtBLl902qU95f4+Du6zPXmI+5wgReWzeN4sDPSaoJyD4CCfVfP2E3/BEaeKk3snTZtcCQMXSGCMMeLUihbtod9QVzSC5i23fYUBlolR+1/V7+g+Ua7JlMwmiEU5Gtsz4efdxM4Mqik5tSA3lpwkSFMucX/M9n0UXK8fkOX11BlR0k+mPNapCB7fLfS8fFI7qzcmr2nCw2Yf3A4equqDgBAbNqx4JrHby83IXWlSkhfAT9BNtN5t882qGlHdsaSKgpKPoghvJPJQZZtnmxt ZaeBqxT6 SvatkQCGgmxycImyOhGFPwYN17B4cjmYUSH+QSYG/P/UVBfsKIHcUsx/7S9v5OEvf6ZUHfbmRBg5SpeIK37ZfmGiTDFGzsaB70LcTg21TMP4v+OPKEy+Yln2pJJlhZlS9jcgI1tma+bKq3FQlsm75b9skqOK8ThFZRe8nShgsV/MZnlDkt6t6H6RFTezCYIDiemg25qmkgasTMccXVGJAZytcSgb1V29CmyHsLlYf8fYnTdpOg0obAhpYmXkbEfzBz+D0fgS7wZYBMJQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 >