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 9B96FD2168F for ; Tue, 15 Oct 2024 12:25:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A53F6B0085; Tue, 15 Oct 2024 08:25:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1557F6B0089; Tue, 15 Oct 2024 08:25:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01BDC6B008A; Tue, 15 Oct 2024 08:25:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D918F6B0085 for ; Tue, 15 Oct 2024 08:25:41 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C864C160F8F for ; Tue, 15 Oct 2024 12:25:31 +0000 (UTC) X-FDA: 82675757556.04.6ACB463 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 80DEA40011 for ; Tue, 15 Oct 2024 12:25:33 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf17.hostedemail.com: domain of joey.gouly@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=joey.gouly@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728995023; a=rsa-sha256; cv=none; b=bncL9h3ODtmcOXd4iakqZXWb2HXUXTnWIBRmT2j5a7s/s79fqN+eX6C8Yxi/1m3O/lyQSm uYwGr3Y/9DsxQ/mAIlvvcw+S6VwBWWR6d44pREJ/LPeAW1nzxoq6VyL5vekTHpTbQsq4TF GGbkpmnRrFl83l/hJVAbpCoGjKgKJcY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf17.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=1728995023; 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=EcDTEARf512YJqUtZUJFtTjK1It0DHuN+lYfzfYdyh0=; b=F4JxcH9wmdMGnTzH5u8iJDSxjI2iYhR9xJg1VcDg7eYvSWWxiFR9GT0Hgf5arKc4yTPg8M kFjnSrSDo2vh1yM2DoJY38VST5WAY9oZCm21KKlxBdKm52aAYvx7nL+XRJF++rU5Ma4sZW j0nYphk4FTkZKA+vesxoTXjXx5M2m4E= 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 E0829DA7; Tue, 15 Oct 2024 05:26:07 -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 394F43F71E; Tue, 15 Oct 2024 05:25:34 -0700 (PDT) Date: Tue, 15 Oct 2024 13:25:29 +0100 From: Joey Gouly To: Will Deacon Cc: Kevin Brodsky , linux-arm-kernel@lists.infradead.org, nd@arm.com, akpm@linux-foundation.org, aneesh.kumar@kernel.org, aneesh.kumar@linux.ibm.com, anshuman.khandual@arm.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, skhan@linuxfoundation.org, szabolcs.nagy@arm.com, tglx@linutronix.de, x86@kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 19/30] arm64: add POE signal support Message-ID: <20241015122529.GA3820764@e124191.cambridge.arm.com> References: <20240822151113.1479789-1-joey.gouly@arm.com> <20240822151113.1479789-20-joey.gouly@arm.com> <47e1537f-5b60-4541-aed1-a20e804c137d@arm.com> <20241009144301.GA12453@willie-the-truck> <20241014171023.GA18295@willie-the-truck> <20241015095911.GA3777204@e124191.cambridge.arm.com> <20241015114116.GA19334@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241015114116.GA19334@willie-the-truck> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 80DEA40011 X-Stat-Signature: nx5s1bcof38hchsg5t3i5qbxmfdh1byh X-Rspam-User: X-HE-Tag: 1728995133-71107 X-HE-Meta: U2FsdGVkX1+90gg6rDCa4oxtw4+MfI43lbZ0AKObl/Mb6AmrWehGpgWHkQlG3Zp6cif1prJzhPZUnDsOS8kXfYzaRGrQ5THKvrFr4UmsujoQfNlgGQEZHE6zQ8cq+rpQ48e1jpElBPrgP3qy3xaXPb0vjj3VsL7ACWwJzO6B1GWsfFZKPeLyOX8HMFn9UhsrmwRoKJL6NPPjaxj7+wzyExki4pk9llGQ5t3PARRGNSLRxAU2/r2sLzJRFxnXYG6/BzYPbZ61KrexhVFxMoP91rUGIcvJkNfftFnMis9KpcxkrhWZGAiU/7j6LYMSfHWks4Tl8KggLKDGf9P9D51LWhBOHsIE3d2S86lzKVR+aSpfKIndba+ENHbSVTsdF2bpWYhsis72K6xna7rVLcJShh0XldHwCb3ZauEn9NjIlyspxfGX/HPkYAwuU/dtIRywWlZkclQ5tBt4vF/JPGKgFwrFzl1jNJn9UOGdDORQX6j7CfSPRG54AJ3hWJd2cM8FY3NHTI03gwceR8fA4j/ayN/BjW0nLtXECWmkDCNzxq6kfwZcY8IpPZ4lnxGatViIdl5EEozEl3thkIqLzP+SbPBbrIgx7uODGNkI6uKl1vcCewGC5FDfa0geo/Tb6K51Mcb/dPt6r0vCUwqDhY/RWbcw3sW3Ewdgt/Kf6iKgoF04osM85simpYaJmXKR1KevcAr7P+tRHM7BBMmeZpL1lTm92zXZDO4jW2GhDfk2sCyf9Zdu7qoUAMhtbf0lprfjTJWLxOGXEwI0XtPldjVHTEmZ4vIxb2BCZrL2gY3Fatrt5aOSIPlhsAFttcbveef9K2862L/EqWp9tJltBTZw6Y4nR9qdqACw98eLeE2F01m77i8zrH5aLcABkW7dkL9Lqd802tFBu7GZ8h/FRCHNl4ooj1qF/WsCFYw5mlw4igtK/TWOsbdDzZqTR59jI3W9Yce1v2ldKRven31oki5 klhUhwFT v+/5TPEe/t0Hu5xzs5tyHHwe5/k6WLsIhpLQTQU9VEUgTw7Byy1Fv4HlckLrMWZwhH+hmg2TovXtx1lfJ9BE+l9fAIYHqrdRBqYHrkHN4JNt16SuW71hwOVfGYj8wqILhDtEXgmWN5oreqZLMKHX7WHNF6w== 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 Tue, Oct 15, 2024 at 12:41:16PM +0100, Will Deacon wrote: > On Tue, Oct 15, 2024 at 10:59:11AM +0100, Joey Gouly wrote: > > On Mon, Oct 14, 2024 at 06:10:23PM +0100, Will Deacon wrote: > > > Kevin, Joey, > > > > > > On Wed, Oct 09, 2024 at 03:43:01PM +0100, Will Deacon wrote: > > > > On Tue, Sep 24, 2024 at 01:27:58PM +0200, Kevin Brodsky wrote: > > > > > On 22/08/2024 17:11, Joey Gouly wrote: > > > > > > @@ -1178,6 +1237,9 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka, > > > > > > sme_smstop(); > > > > > > } > > > > > > > > > > > > + if (system_supports_poe()) > > > > > > + write_sysreg_s(POR_EL0_INIT, SYS_POR_EL0); > > > > > > > > > > At the point where setup_return() is called, the signal frame has > > > > > already been written to the user stack. In other words, we write to the > > > > > user stack first, and then reset POR_EL0. This may be problematic, > > > > > especially if we are using the alternate signal stack, which the > > > > > interrupted POR_EL0 may not grant access to. In that situation uaccess > > > > > will fail and we'll end up with a SIGSEGV. > > > > > > > > > > This issue has already been discussed on the x86 side, and as it happens > > > > > patches to reset PKRU early [1] have just landed. I don't think this is > > > > > a blocker for getting this series landed, but we should try and align > > > > > with x86. If there's no objection, I'm planning to work on a counterpart > > > > > to the x86 series (resetting POR_EL0 early during signal delivery). > > > > > > > > Did you get a chance to work on that? It would be great to land the > > > > fixes for 6.12, if possible, so that the first kernel release with POE > > > > support doesn't land with known issues. > > > > > > Looking a little more at this, I think we have quite a weird behaviour > > > on arm64 as it stands. It looks like we rely on the signal frame to hold > > > the original POR_EL0 so, if for some reason we fail to allocate space > > > for the POR context, I think we'll return back from the signal with > > > POR_EL0_INIT. That seems bad? > > > > If we don't allocate space for POR_EL0, I think the program recieves SIGSGEV? > > > > setup_sigframe_layout() > > if (system_supports_poe()) { > > err = sigframe_alloc(user, &user->poe_offset, > > sizeof(struct poe_context)); > > if (err) > > return err; > > } > > > > Through get_sigframe() and setup_rt_frame(), that eventually hets here: > > > > handle_signal() > > ret = setup_rt_frame(usig, ksig, oldset, regs); > > > > [..] > > > > signal_setup_done(ret, ksig, test_thread_flag(TIF_SINGLESTEP)); > > > > void signal_setup_done(int failed, struct ksignal *ksig, int stepping) > > { > > if (failed) > > force_sigsegv(ksig->sig); > > else > > signal_delivered(ksig, stepping); > > } > > > > So I think it's "fine"? > > Ah, yes, sorry about that. I got confused by the conditional push in > setup_sigframe(): > > if (system_supports_poe() && err == 0 && user->poe_offset) { > ... > > which gives the wrong impression that the POR is somehow optional, even > if the CPU supports POE. So we should drop that check of > 'user->poe_offset' as it cannot be NULL here. > > We also still need to resolve Kevin's concern, which probably means > keeping the thread's original POR around someplace. That was cargo culted (by me) from the rest of the function (apart from TPIDR2 and FPMR). I think Kevin is planning on sending his signal changes still, but is on holiday, maybe he can remove the last part of the condition as part of his series. Thanks, Joey