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 DBD80D1D876 for ; Tue, 15 Oct 2024 15:01:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 799956B0088; Tue, 15 Oct 2024 11:01:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 71FBB6B0089; Tue, 15 Oct 2024 11:01:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E7E46B008A; Tue, 15 Oct 2024 11:01:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3F4616B0088 for ; Tue, 15 Oct 2024 11:01:58 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 83C5DA16E0 for ; Tue, 15 Oct 2024 15:01:41 +0000 (UTC) X-FDA: 82676151264.21.8E53583 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf07.hostedemail.com (Postfix) with ESMTP id 949E74000E for ; Tue, 15 Oct 2024 15:01:45 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729004443; 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=iHG/Gbx4wxyz4XiKAHoTWGclnCcTepNBq2ZEGp4DCJI=; b=XUW2qYqV4n5qrJTpEv1jydNk/ikD3tDCyoLpdxInmnk/NvybkFinGIJI20MYUBOqj/O+R3 gIb0poNkL47N+WJNwh4KLLLCNQAfn7JRHJPh9f+S7uFn5iTOhSJwmQ0z0LjQw8morgQRnz Wu2kl3HfXPl3Jj5iUg12h8PEd6ymYY0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729004443; a=rsa-sha256; cv=none; b=GugjiPmcng6wpICy08ieCfg3fdAWa9gde/iPDDODIJMKhlMn/mcFlIztksgqWYS5EDcOyb Hf7R0LutZJaXG8mMrDerA3ks2x1usTc8uNCOAArWUhvehoAQgR3oOcY3NySczFH87mG0j4 fDlGqj+9bIU5icWm0DfWQyRQ+aYiiJY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 45DD8A43252; Tue, 15 Oct 2024 15:01:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18141C4CEC6; Tue, 15 Oct 2024 15:01:49 +0000 (UTC) Date: Tue, 15 Oct 2024 16:01:47 +0100 From: Catalin Marinas To: Will Deacon Cc: Joey Gouly , 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, 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: 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: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 949E74000E X-Stat-Signature: z7exba6pbxpyxwgah7rmxuuad15jmpj9 X-HE-Tag: 1729004505-672830 X-HE-Meta: U2FsdGVkX19pieFNy1+X5evOloWcvnGrTbLH51n25r86WPSttb8Fvs5Fmc72uLch5KR+e2vOgMSwsqJ2wZCxAiYrZLQk5J1MvEWDZ9+HZFbA66/dCk2KeR/dq65bzMZE7LxptW8CDeJ1tBEHow6PBEwQUcyeWksm1Qbdqh+CCJGXuwpjqX8isvZrE5hEIgL7qzNfYRElel7PqzDNojeR93YraEmqEvAjKqkr1PXBjjvLKli0Fyk9R0TPsyI2c1YmTksKxwgEq/NtIyda4E/yu+HsoW4sc2RLcoByJre+isJJgXLuq4LEQKTdf014GD5KYUphunRbHafO7TxbEjeaoTFD7ODtqV/WhVee0oAiF8YxJW6TB4F4ClAyh75f+XIVKnfs8sEPh1PJV/2kOJhyaufWghlaasHO78Bl/eAwAHDc1LMz2xE0OR+pYfnuO490TupgD6SQrj6ofr9Rs6/HYu0M3wP9f/MAwePz6bvb8lCfXO141ICf+PR5LWMBKzFJMx6lUnMw+wPK7ky18QMJcFm8rC0fo7Pt0wSCejZgPesMu+3R1GdH0k/eFsFKQTO2EKBT7Lt0gVAgUTyfnGpfazkQlhj+lFBpd9mAIbx9DxEF5b1XASadAEpvr3yZtMMUrnQyhm7sHTJKEYOB4u55+CyVY+K6hfi9OdujbcCuUfTqBp41s618/1oRPHfnXVV1AZlrmuxPamLZrdt+1R6lQEB4qyc43LmOmluDl+5p+br67VNet6yRxFpAwvVMeAp/dp8uVNQueMeOu9xtVCwFte2QInYzHrimCqv+YDN/NVlqCcWT3Ks9dknJoeETsOlseVtB/fNKp4MGnK5zvaN5piZviupyqd0HyPM2hdoFU5Z1wLxbizAht8Ia2MbsIh+3cVYR6/uwHtqz+/qACJwDPrZb8VTPS7gkkoiN8c8i9eyLHObhdC0VHWCFdR5fh1fvV/eoWytQ2KkJ3X5+JY6 Xl1n9ghU cBtdEQZRl0cqiOVlForR0VpKmmLkvkJwiKaKujoTJid7zuoDkqIGAavkDHA73eRQMlPQxOWl6PYoMtnIfvpR0sD3yK3Da0IfXpEFRmClAeNL4ZUEBnz/+N0dinCJqqd3pKcQsDB4WZQPdHFeFip8oHz6gTrfkdTrgS9V+hqeVaivAq/Sf/LIX8UCv+X88b1p08Omn8SgHM/3yKp92gKyZtCZlcXtXho+UWNzvUi09lBfo7nvLItc7D5mLWysd94a9Gu59aGezd9T1ngo5dkJXSq++qoeML+mpeFHGX0zGa9/JUGJiLxrPSdduXha3xPd9+A2BokH41A3Zj5hNx0PGVdw0yyazQskjdfb2 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: > > > 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. I agree, we should remove this check as it's confusing. > We also still need to resolve Kevin's concern, which probably means > keeping the thread's original POR around someplace. If we fail to allocate context for POR_EL0 (or anything else), we'll deliver a SIGSEGV. I think it's quite likely that the SIGSEGV will also fail to allocate context we end up with a fatal SIGSEGV. Not sure the user can affect the allocation/layout, though it can change stack attributes where the frame is written. Assuming that the user tricks the kernel into failing to write the context but allows it to succeed on the resulting SIGSEGV, POR_EL0 wouldn't have been reset and the SIGSEGV context will still have the original value. I don't think we need to do anything here for 6.12. However, in for-next/core, we have gcs_signal_entry() called after resetting POR_EL0. If this fails, we can end up with a new POR_EL0 on sigreturn (subject to the above user toggling permissions). I think this needs to be fixed, POR_EL0 only reset when we know we are going to deliver the signal. -- Catalin