From nobody Fri Dec 19 18:45:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B96ED20C032; Wed, 4 Dec 2024 15:22:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325746; cv=none; b=qg1eSfF+sgELY3Pxq5MxyrmOF/tqDpPCzTojSmp2r1DkQECMXJZ4xzSdyc2Kfhqy3ODLuljZlCBsCHuyjQyqXCU0jXD1nzuFB5ja5VzOq9JijZilemqr8OM00IV4pqiHbQzTep5VGvyzGRe/1EDqV9vK4OnVORgB9lugCVdK85c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325746; c=relaxed/simple; bh=LpOVQoMlpE/E8rUSHH5zwrqMIfcMHJ5yw+nwZF82uAs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=dcTGTrsh1cIeq8jxW7NU+tOgd5GZHCL/3QOjaRVIunSijwwsYlp8KqEFPsq4bAEZeyD0UdDRjL7VhF5Ntq1/nwD2S2ooMNeCh5TAhLsc6KaLheHDqjYq5PaQIVXPs+NFNnzldVPlWj4pRXvugqAYap/hNQibytKzqlTxHb/30Dc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NGXcSMjF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NGXcSMjF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA593C4CEDF; Wed, 4 Dec 2024 15:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733325746; bh=LpOVQoMlpE/E8rUSHH5zwrqMIfcMHJ5yw+nwZF82uAs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=NGXcSMjFEK3Gb5ZThhTotb8LtObyRrVYXZMwWsjbtfNNERt/rSoOgxKD4cfll0oT1 gA4Vir1uILjYXAxidPmQWIayCKAJFXCxh3QEWX1ClTDpAtN+oX46EtV3AV1qarfLJT 1gsDKErmPYoPUi3vgG8jWS4hBB7Oe+uBbsHpYM0tFBE/Ga1pvtzf8pkpEosmauaZx7 moc5xQAf/foWsJSDEs+AEuTGL1Mtx0fOtyjc4RXaPCx4v8rjB2qHOQ6WPW5+pro1TK PH3Z8ZytH+xdIGUt6G2xRMLdYMd2TGVNtqUk6PcmrVufDsg/ngoh6LdMt43T08YwUu oPROgdoK9zFkA== From: Mark Brown Date: Wed, 04 Dec 2024 15:20:49 +0000 Subject: [PATCH v2 1/6] arm64/sme: Flush foreign register state in do_sme_acc() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20241204-arm64-sme-reenable-v2-1-bae87728251d@kernel.org> References: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> In-Reply-To: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> To: Catalin Marinas , Will Deacon Cc: Mark Rutland , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Brown , stable@vger.kernel.org X-Mailer: b4 0.15-dev-9b746 X-Developer-Signature: v=1; a=openpgp-sha256; l=1524; i=broonie@kernel.org; h=from:subject:message-id; bh=LpOVQoMlpE/E8rUSHH5zwrqMIfcMHJ5yw+nwZF82uAs=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBnUHOpV1gwjo0EzhOoXMD37trHVNnA76xlj4H70URa 8/Ka34eJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZ1BzqQAKCRAk1otyXVSH0JU5B/ 9tJ8ahfl3ZVfslu1hDK5SdC1zHiWbpICVSKPprRqsqf34h8Q5rtN3W3y6cDJIAhS3VnYqrnyQ34PdB qQPuOe4L3HsDy+RZfLSY6gJZr/3/vHtN6tXCcFuQZ2KZAu7S2iDU+MfBRWUSSW2B5Nw5nW4AXCgnO7 nYmwctPULF9HxwZ5Jk+zd9Kf5ym1S+3cEb5SjgSbMH9/EI93o0sbQqh+cOJ37BAbCmDS3CTdikqzPC rMDC2rIgm0u+ufDvuyO389ZOY8CxdxzZGumTrRX26WEaRStIyFVTUaI5OgH7XXS/xznwK61W6grplw 4ANmhMEhh14yXBZYEuOsu3KK6qRKC6 X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB When do_sme_acc() runs with foreign FP state it does not do any updates of the task structure, relying on the next return to userspace to reload the register state appropriately, but leaves the task's last loaded CPU untouched. This means that if the task returns to userspace on the last CPU it ran on then the checks in fpsimd_bind_task_to_cpu() will incorrectly determine that the register state on the CPU is current and suppress reload of the floating point register state before returning to userspace. This will result in spurious warnings due to SME access traps occuring for the task after TIF_SME is set. Call fpsimd_flush_task_state() to invalidate the last loaded CPU recorded in the task, forcing detection of the task as foreign. Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for S= ME") Reported-by: Mark Rutlamd Signed-off-by: Mark Brown Cc: stable@vger.kernel.org --- arch/arm64/kernel/fpsimd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 8c4c1a2186cc510a7826d15ec36225857c07ed71..eca0b6a2fc6fa25d8c850a5b9e1= 09b4d58809f54 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1460,6 +1460,8 @@ void do_sme_acc(unsigned long esr, struct pt_regs *re= gs) sme_set_vq(vq_minus_one); =20 fpsimd_bind_task_to_cpu(); + } else { + fpsimd_flush_task_state(current); } =20 put_cpu_fpsimd_context(); --=20 2.39.5 From nobody Fri Dec 19 18:45:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 261B020C47D for ; Wed, 4 Dec 2024 15:22:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325748; cv=none; b=KYMU8eBQ6e+9e9U8yvGyCLSwnqNafbLteTuTZfIsySf4m3vllqubPw1rI5HueyDCr5fgYR+N03sIwp8ZKn0qEqW8rmD7HJeTZ1N0xDzWnVbjOUop0WZ5ZALICe+Ck/nTatf5YE9TLynwtfGxumZ/dNvMvpH5NmBGlz+HGZVDGik= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325748; c=relaxed/simple; bh=fwkQ2FXE6pq57Zq+2np3KAdjth1F3BAf6kMutQobcPY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=trLpX1LYp79KgJbMPaKHR/a72IjyryOeXp0krrf55MUQzqBo/6PerpWxKKNIQBqbENexBHd8/hrKWbojkNDUBuPIKvtGI2uoveFqyYsNSkKxsHUZPUD8BStJ6UPYcuS1a57XNwVGou+1k6TmGeI+IkugOI+YlucWQpY4FqWoBnY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=epS7muEe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="epS7muEe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1B18C4CED2; Wed, 4 Dec 2024 15:22:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733325748; bh=fwkQ2FXE6pq57Zq+2np3KAdjth1F3BAf6kMutQobcPY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=epS7muEeP9lQIxwVtpBOEZfTUD0dsC90heQReQpjO5hSMDjQjehvJiOWNMEt5EZyV Qzd1J2/mQ9EsWaCv7SFchHqtBbmUlRZ2c0o4hSqohK7YgGEjJ86kAqC35Stjhmxuwi xIGiafCiyU6PJ/8ytGtdm5v64UKhjDqweVbn+3j2/ZCNwPM+miTwgqM5jUTOq1yBVD bs5kHwXSsZKZEx70b4p0EUneQwhGzEDx4v48roXtTQ2SrGYp/W/DgsD+ZOKUmMFXsW jHwnlx9WcXcLg6psEzSmW5j89JD3B+fyoO/xkl1vl+Aep0W5R3ksHMHKQ9FyvxT4T8 P2+F7BSdD6K3Q== From: Mark Brown Date: Wed, 04 Dec 2024 15:20:50 +0000 Subject: [PATCH v2 2/6] arm64/fp: Don't corrupt FPMR when streaming mode changes Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20241204-arm64-sme-reenable-v2-2-bae87728251d@kernel.org> References: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> In-Reply-To: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> To: Catalin Marinas , Will Deacon Cc: Mark Rutland , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Brown X-Mailer: b4 0.15-dev-9b746 X-Developer-Signature: v=1; a=openpgp-sha256; l=1433; i=broonie@kernel.org; h=from:subject:message-id; bh=fwkQ2FXE6pq57Zq+2np3KAdjth1F3BAf6kMutQobcPY=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBnUHOpaUAs0CFqi8g5AEDwSl46+wYe2DIE2hvmh1nQ 7ZNS+yOJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZ1BzqQAKCRAk1otyXVSH0Hn0B/ 9VJPrFKOwDan2vT7C2sJe2gkAlzuDlnRvwYUVmOmEC+hyjxz0oxkJ72W+vZD/3ARoKBOO2aJyXtkFg X/4cmj2Y7cBdf9sPaTiqHG5lCSKOwptrpInRbgvIviUQqiTsMvY5G2i1c5jDCFu/30qASLdspMVGzF YSRBEdob0x1qVbfN5V5sytxnsV/txBc3wzGywRnNjwc9hGdEv3EOKAYhqyKBk3lorL7GpDsX2eTSbb w73NyNm5JxQLhQiKQTUXYVsNzaOni64A45ufDLjOfrmA1mYyJVmH6OiHnoFOLqqt6f5z/I+DhKk0YB pZVdXllCnDoQZM2Oz5zWMzAyJFHuBT X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB When we enter or exit streaming more FPMR is reset to 0. This means that when restoring the floating point state from memory we need to restore FPMR after we restore SVCR, otherwise if we are entering or exiting streaming mode as part of loading the new state the value of FPMR will be corrupted. Fixes: 203f2b95a882 ("arm64/fpsimd: Support FEAT_FPMR") Signed-off-by: Mark Brown --- arch/arm64/kernel/fpsimd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index eca0b6a2fc6fa25d8c850a5b9e109b4d58809f54..a3bb17c88942eba031d26e9f75a= d46f37b6dc621 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -359,9 +359,6 @@ static void task_fpsimd_load(void) WARN_ON(preemptible()); WARN_ON(test_thread_flag(TIF_KERNEL_FPSTATE)); =20 - if (system_supports_fpmr()) - write_sysreg_s(current->thread.uw.fpmr, SYS_FPMR); - if (system_supports_sve() || system_supports_sme()) { switch (current->thread.fp_type) { case FP_STATE_FPSIMD: @@ -413,6 +410,9 @@ static void task_fpsimd_load(void) restore_ffr =3D system_supports_fa64(); } =20 + if (system_supports_fpmr()) + write_sysreg_s(current->thread.uw.fpmr, SYS_FPMR); + if (restore_sve_regs) { WARN_ON_ONCE(current->thread.fp_type !=3D FP_STATE_SVE); sve_load_state(sve_pffr(¤t->thread), --=20 2.39.5 From nobody Fri Dec 19 18:45:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2740720CCC7; Wed, 4 Dec 2024 15:22:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325750; cv=none; b=Nt8G+lXtwDcUR956RbGO1Eg0R4l0wqEc2UW8GkRF0KCIP+TwGmFAIvT1Qg0TBsbkaxnaVPk+rOATA7qHM+2aK9O9UDX12wunAL1w97YuIgNgDODRrJ/whhBEg04ZxevppZdtUJK59eI6VZZ3Y/gtCV9ny0PmonVgT+Ixhy+5XZg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325750; c=relaxed/simple; bh=A8QKBxilDmxPa7rkbda6zcbE9W7eNHPT2bdz3YleFLw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=CkVAr+TKMBgMZRpzx8Ctg7YhleInPraAJ2sO1/P8bWnriIyMci6/uMALUoJ3hAmsDHS+CqxzHbKJiNLiH2ApOp9tQbhEsJoWsTIHPEQYacjjWllZl0ikzuE7eZA7gpEKbBh7qs3bq45cHVEI8WrF2QL4Q+sjVnr6tEwAhb5HPrk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QNj5hXem; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QNj5hXem" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F4F9C4CED2; Wed, 4 Dec 2024 15:22:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733325750; bh=A8QKBxilDmxPa7rkbda6zcbE9W7eNHPT2bdz3YleFLw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=QNj5hXemT+0ygrwbrgagcUNKOZv7DgPtgEFPYb2ASRGxh801B9/Gxxd88fI+jbDvg JXiP3zd1ThdTKB0crkPoFya/IKM/m0aBjYCv7N4DqXshIk17EBw3LMNPR4GsRxCWRd ESiLrVPAn2oXczQspoZnSOFa0AY2xWyM1v7JTtEhAjUacMhtsC6mWdAaQXVg9U35Yf a6VzE0jAv80ZkgP8JErM2iPhqJgas5NSOVaAUpJiQEyCY2rtg8TybLbu+iISNbPm5O 6o5ZWZ4UKPLGy180R+7AvMjUUAdpu3cn7mRDnYXxtfxpFwfzudscBcgI34+mNxa+S4 ZDhyxvNCXkzWQ== From: Mark Brown Date: Wed, 04 Dec 2024 15:20:51 +0000 Subject: [PATCH v2 3/6] arm64/ptrace: Zero FPMR on streaming mode entry/exit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20241204-arm64-sme-reenable-v2-3-bae87728251d@kernel.org> References: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> In-Reply-To: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> To: Catalin Marinas , Will Deacon Cc: Mark Rutland , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Brown , stable@vger.kernel.org X-Mailer: b4 0.15-dev-9b746 X-Developer-Signature: v=1; a=openpgp-sha256; l=2536; i=broonie@kernel.org; h=from:subject:message-id; bh=A8QKBxilDmxPa7rkbda6zcbE9W7eNHPT2bdz3YleFLw=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBnUHOqPfutP7bJSiz1k/7SJhcoIeMOBJXZS1GuIf38 grLqUyCJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZ1BzqgAKCRAk1otyXVSH0K5oB/ 9g8XrD26deExaGvYbmtEB2rk9DdkgD0udiS0bq/MVMNeUZAP6wa0bz7mKAWRk9vEZ7UQ2XhBC+5JOU Y74TcXmBDAxrhN+kxiv/EwXqzTyvLBQ7dmz4sr6sfRUW2jIkzyawXKXPWByssW6Cqu0+Z+lCylgevf V9tCwn/IbrKcvHinej/SrO4Z1BvUjs4B+ea0iAmbCpTipdlARj8HTOESCozy38MrlHXpktcPv5Nzuh 5Z6YyRTBGFWARBoyqqtAMrB4UKfclQrK1g4flJL01GNB5xki7imPM+Xdf+sclqpAKtOMX1ErxyGIQu ETIrsydK0mSkxcXkHB0+UfZC4CPCFD X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB When FPMR and SME are both present then entering and exiting streaming mode clears FPMR in the same manner as it clears the V/Z and P registers. Since entering and exiting streaming mode via ptrace is expected to have the same effect as doing so via SMSTART/SMSTOP it should clear FPMR too but this was missed when FPMR support was added. Add the required reset of FPMR. Since changing the vector length resets SVCR a SME vector length change implemented via a write to ZA can trigger an exit of streaming mode and we need to check when writing to ZA as well. Fixes: 4035c22ef7d4 ("arm64/ptrace: Expose FPMR via ptrace") Signed-off-by: Mark Brown Cc: stable@vger.kernel.org --- arch/arm64/kernel/ptrace.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index e4437f62a2cda93734052c44b48886db83d75b3e..43a9397d5903ff87b608befdcae= d3f9a7e48f976 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -877,6 +877,7 @@ static int sve_set_common(struct task_struct *target, const void *kbuf, const void __user *ubuf, enum vec_type type) { + u64 old_svcr =3D target->thread.svcr; int ret; struct user_sve_header header; unsigned int vq; @@ -908,8 +909,6 @@ static int sve_set_common(struct task_struct *target, =20 /* Enter/exit streaming mode */ if (system_supports_sme()) { - u64 old_svcr =3D target->thread.svcr; - switch (type) { case ARM64_VEC_SVE: target->thread.svcr &=3D ~SVCR_SM_MASK; @@ -1008,6 +1007,10 @@ static int sve_set_common(struct task_struct *target, start, end); =20 out: + /* If we entered or exited streaming mode then reset FPMR */ + if ((target->thread.svcr & SVCR_SM) !=3D (old_svcr & SVCR_SM)) + target->thread.uw.fpmr =3D 0; + fpsimd_flush_task_state(target); return ret; } @@ -1104,6 +1107,7 @@ static int za_set(struct task_struct *target, unsigned int pos, unsigned int count, const void *kbuf, const void __user *ubuf) { + u64 old_svcr =3D target->thread.svcr; int ret; struct user_za_header header; unsigned int vq; @@ -1184,6 +1188,10 @@ static int za_set(struct task_struct *target, target->thread.svcr |=3D SVCR_ZA_MASK; =20 out: + /* If we entered or exited streaming mode then reset FPMR */ + if ((target->thread.svcr & SVCR_SM) !=3D (old_svcr & SVCR_SM)) + target->thread.uw.fpmr =3D 0; + fpsimd_flush_task_state(target); return ret; } --=20 2.39.5 From nobody Fri Dec 19 18:45:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 141DA20CCEA; Wed, 4 Dec 2024 15:22:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325752; cv=none; b=heQwKSX8PfGaK63n/8T9Pn1nJBZaJjbvP/9tqTUJVHXhr25n2vaclAOOf3nXX+B91FdP0gvtFVsLL6J9jFKSYMrBfLK2iXT9GFjI2WCWWkFXQ5j8teRen6EG/X6tamDV/AO9nrQvFJoR0dH9b5Q4Q0COOYKKgZLTKNwrnRz4jDk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325752; c=relaxed/simple; bh=lZE0yTF3Wn3zm9BaDbx5EJVtSvWlxgzUZ0o5624BVkc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=cdHnx0+jYjQb2gZo8aho4SXT8EnSg1Ir6c5kADoNzhThA3Ko4LKobhR3jJGX8xBeLu0ijUPsFJtDoswxbkAk8DzI3bdhcoL2jQ57F1NeHsaXRgeThNT2rxKkg4LZN5YC7vKKl1pglQP1TPN9lJDSRnzt4vWh1Azk0ppT34/3NRs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qsUjrzZo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qsUjrzZo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67DD1C4CECD; Wed, 4 Dec 2024 15:22:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733325752; bh=lZE0yTF3Wn3zm9BaDbx5EJVtSvWlxgzUZ0o5624BVkc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=qsUjrzZoYvGeW4O1Qo2S/QEo1kpj3bCn/WaqU3FmeHw2BoTS92MADRiV9v+ZUEYma PL6q7ETvLd/+nb+k9JNrD/XMk1wJWoM9W5vYkPkbF0s0BVOcxObOU3O5I5WwDIaDzO dYlFyTfadRQpnmFZkhX+n7l83OT33Kj3xcnLodcpUY0pckUkZAK1rsG4PCiQ0pIGEF 5ZlvBF9H6It2QWCjfWr39rwp4fBuagiKsVFIsy9Y9jpXyqPo26ZcChEGq1B6IU1FKd CzgS6jT/0W+tqbO2kk+K27LrqkCSlLhTLBQGGgAG55V4vKk19dfOVAfzgCG7JWOZUw kLNqqyhwFtqVg== From: Mark Brown Date: Wed, 04 Dec 2024 15:20:52 +0000 Subject: [PATCH v2 4/6] arm64/signal: Avoid corruption of SME state when entering signal handler Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20241204-arm64-sme-reenable-v2-4-bae87728251d@kernel.org> References: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> In-Reply-To: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> To: Catalin Marinas , Will Deacon Cc: Mark Rutland , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Brown , stable@vger.kernel.org X-Mailer: b4 0.15-dev-9b746 X-Developer-Signature: v=1; a=openpgp-sha256; l=6215; i=broonie@kernel.org; h=from:subject:message-id; bh=lZE0yTF3Wn3zm9BaDbx5EJVtSvWlxgzUZ0o5624BVkc=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBnUHOrNgOudoKrDy1LNoXO+30vsuX1Sq99+Z0u/GpF cnOco76JATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZ1BzqwAKCRAk1otyXVSH0G9vB/ 9WZhYOqn/+ue9mmPEZKnaxHPg8zv3uNoHg89HImh9V8P6iMBLBqKwK63OlDzhtRPGDiBNDpYJXTcgK TTCxYPgsBxqndrDp3TlvKUkf3rTA4G5DF+Lg+x1GHd6VkXVRaliTztue1LU8ZRjIc5zyOrsepipQRG 68KD1dl/Xbt0gT1KgKWr12hOSYG0vyqgeDni5eM4mfajRtdIXwJ/XXwRwHjZAzLwezxGr+e4mzHRqQ an2+EfV0z7DFhpLlFM2tqpcoEMt06Rbf5chVfCrNQnAUOjHR6g35eIfs7+MhHFy7Fz7WSGS9XMwWBn MeZMOcqxqz6bI92ziLgC6eUvv4dJbE X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB We intend that signal handlers are entered with PSTATE.{SM,ZA}=3D{0,0}. The logic for this in setup_return() manipulates the saved state and live CPU state in an unsafe manner, and consequently, when a task enters a signal handler: * The task entering the signal handler might not have its PSTATE.{SM,ZA} bits cleared, and other register state that is affected by changes to PSTATE.{SM,ZA} might not be zeroed as expected. * An unrelated task might have its PSTATE.{SM,ZA} bits cleared unexpectedly, potentially zeroing other register state that is affected by changes to PSTATE.{SM,ZA}. Tasks which do not set PSTATE.{SM,ZA} (i.e. those only using plain FPSIMD or non-streaming SVE) are not affected, as there is no resulting change to PSTATE.{SM,ZA}. Consider for example two tasks on one CPU: A: Begins signal entry in kernel mode, is preempted prior to SMSTOP. B: Using SM and/or ZA in userspace with register state current on the CPU, is preempted. A: Scheduled in, no register state changes made as in kernel mode. A: Executes SMSTOP, modifying live register state. A: Scheduled out. B: Scheduled in, fpsimd_thread_switch() sees the register state on the CPU is tracked as being that for task B so the state is not reloaded prior to returning to userspace. Task B is now running with SM and ZA incorrectly cleared. Fix this by: * Checking TIF_FOREIGN_FPSTATE, and only updating the saved or live state as appropriate. * Using {get,put}_cpu_fpsimd_context() to ensure mutual exclusion against other code which manipulates this state. To allow their use, the logic is moved into a new fpsimd_enter_sighandler() helper in fpsimd.c. This race has been observed intermittently with fp-stress, especially with preempt disabled, commonly but not exclusively reporting "Bad SVCR: 0". While we're at it also fix a discrepancy between in register and in memory entries. When operating on the register state we issue a SMSTOP, exiting streaming mode if we were in it. This clears the V/Z and P register and FPMR, and resets FPSR to 0x800009f but does not change ZA, ZT or FPCR. The in memory version clears all the user FPSIMD state including FPCR and FPSR but does not clear FPMR. Update the code to implement the changes the hardware implements. Fixes: 40a8e87bb3285 ("arm64/sme: Disable ZA and streaming mode when handli= ng signals") Signed-off-by: Mark Brown Cc: stable@vger.kernel.org --- arch/arm64/include/asm/fpsimd.h | 1 + arch/arm64/kernel/fpsimd.c | 40 +++++++++++++++++++++++++++++++++++++= +++ arch/arm64/kernel/signal.c | 19 +------------------ 3 files changed, 42 insertions(+), 18 deletions(-) diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsim= d.h index f2a84efc361858d4deda99faf1967cc7cac386c1..09af7cfd9f6c2cec26332caa4c2= 54976e117b1bf 100644 --- a/arch/arm64/include/asm/fpsimd.h +++ b/arch/arm64/include/asm/fpsimd.h @@ -76,6 +76,7 @@ extern void fpsimd_load_state(struct user_fpsimd_state *s= tate); extern void fpsimd_thread_switch(struct task_struct *next); extern void fpsimd_flush_thread(void); =20 +extern void fpsimd_enter_sighandler(void); extern void fpsimd_signal_preserve_current_state(void); extern void fpsimd_preserve_current_state(void); extern void fpsimd_restore_current_state(void); diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index a3bb17c88942eba031d26e9f75ad46f37b6dc621..2b045d4d8f71ace5bf01a596dda= 279285a0998a5 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1696,6 +1696,46 @@ void fpsimd_signal_preserve_current_state(void) sve_to_fpsimd(current); } =20 +/* + * Called by the signal handling code when preparing current to enter + * a signal handler. Currently this only needs to take care of exiting + * streaming mode and clearing ZA on SME systems. + */ +void fpsimd_enter_sighandler(void) +{ + if (!system_supports_sme()) + return; + + get_cpu_fpsimd_context(); + + if (test_thread_flag(TIF_FOREIGN_FPSTATE)) { + /* + * Exiting streaming mode zeros the V/Z and P + * registers and FPMR. Zero FPMR and the V registers, + * marking the state as FPSIMD only to force a clear + * of the remaining bits during reload if needed. + */ + if (current->thread.svcr & SVCR_SM_MASK) { + memset(¤t->thread.uw.fpsimd_state.vregs, 0, + sizeof(current->thread.uw.fpsimd_state.vregs)); + current->thread.uw.fpsimd_state.fpsr =3D 0x800009f; + current->thread.uw.fpmr =3D 0; + current->thread.fp_type =3D FP_STATE_FPSIMD; + } + + current->thread.svcr &=3D ~(SVCR_ZA_MASK | + SVCR_SM_MASK); + + /* Ensure any copies on other CPUs aren't reused */ + fpsimd_flush_task_state(current); + } else { + /* The register state is current, just update it. */ + sme_smstop(); + } + + put_cpu_fpsimd_context(); +} + /* * Called by KVM when entering the guest. */ diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 14ac6fdb872b9672e4b16a097f1b577aae8dec50..79c9c5cd0802149b3cde20b3986= 17437d79181f2 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -1487,24 +1487,7 @@ static int setup_return(struct pt_regs *regs, struct= ksignal *ksig, /* TCO (Tag Check Override) always cleared for signal handlers */ regs->pstate &=3D ~PSR_TCO_BIT; =20 - /* Signal handlers are invoked with ZA and streaming mode disabled */ - if (system_supports_sme()) { - /* - * If we were in streaming mode the saved register - * state was SVE but we will exit SM and use the - * FPSIMD register state - flush the saved FPSIMD - * register state in case it gets loaded. - */ - if (current->thread.svcr & SVCR_SM_MASK) { - memset(¤t->thread.uw.fpsimd_state, 0, - sizeof(current->thread.uw.fpsimd_state)); - current->thread.fp_type =3D FP_STATE_FPSIMD; - } - - current->thread.svcr &=3D ~(SVCR_ZA_MASK | - SVCR_SM_MASK); - sme_smstop(); - } + fpsimd_enter_sighandler(); =20 if (ksig->ka.sa.sa_flags & SA_RESTORER) sigtramp =3D ksig->ka.sa.sa_restorer; --=20 2.39.5 From nobody Fri Dec 19 18:45:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3EE2620CCEC for ; Wed, 4 Dec 2024 15:22:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325754; cv=none; b=jsJFB2opsyDJOK4narXUPOOvcEsf1e1rHVQpZwUhiiEgrGWWYZqb22Yl6m24oy7HJPY65Wpz/RPS4CwhkhvorsGFWEGcMXvBOuE373Q42azXFhBguKjSOI2+rhQULNvLla+cpVTTYB68OX4mj/CnnJWV0ceXUSFg99rmAujvxSA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325754; c=relaxed/simple; bh=NfLmqQjhH+UlQ7Y+G2ykkZMplv/ejiQc6RhXEP3cv9c=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=K1/CqDI07zoh3rN4EjBXImAgvQUka+RcEutERLIyTV1IHekLwFJBCwEwDlVjfuQOZERfDEmKTI1UjTOYE7xVGdh1RER9uAd+iQBrj9helmr/d5ENp9ce+ASV0CqzmCEyvKv4cnxelX6kOvvl57CdMBL2SY/R0dxH8xs+9dS3y4Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AA9I21OQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AA9I21OQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FDB5C4CECD; Wed, 4 Dec 2024 15:22:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733325753; bh=NfLmqQjhH+UlQ7Y+G2ykkZMplv/ejiQc6RhXEP3cv9c=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=AA9I21OQzvXTD9ePUDrr5h9Z0wOHDh6jF35EaoAYsUMqsSJQxW38z3QkOpd4uHYoB tEfGXOdRKuzb7ELZCXUubD3N98i0JUifocbJEzfA480VJGyFRORsIzShFIiRFiyoSO /nKknR1fAaiEFa+JxnIfv5yDGERVC4xKTC548FcWGSMgmdS6NgymsjJgustYy8B3UM eMjXR4jiRCqSQqOhLoyzk/MlxiWk6xMGFTz44c+XJM0BZYTT4S/oH3+uwZnQtON94C HbdNt8+GPmbtflcy1j94owT2fq5Im2hpgRnGWSYtqbBC5qxwW5CrqJ/kULLBDpI8vc 77noG1ZMROR0g== From: Mark Brown Date: Wed, 04 Dec 2024 15:20:53 +0000 Subject: [PATCH v2 5/6] arm64/sme: Reenable SME Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20241204-arm64-sme-reenable-v2-5-bae87728251d@kernel.org> References: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> In-Reply-To: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> To: Catalin Marinas , Will Deacon Cc: Mark Rutland , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Brown X-Mailer: b4 0.15-dev-9b746 X-Developer-Signature: v=1; a=openpgp-sha256; l=769; i=broonie@kernel.org; h=from:subject:message-id; bh=NfLmqQjhH+UlQ7Y+G2ykkZMplv/ejiQc6RhXEP3cv9c=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBnUHOswXh9Qp87YFQNiApq82JF8iKPIsacXChbC9NO xUMJkDKJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZ1BzrAAKCRAk1otyXVSH0AmYB/ 4mHv/OIIIvF/5wo69xV2tpZJVLWHKrR4uBygEFPUTRdj9ULex3KfhOg6bIOKzNTK2cFoNeQrrGdI28 djJn+ZpWtW75a077cHznj9M27QiE6xdldBJCpUOrhSwhJG4k0xvF/iyjfXdsFbk/d/Pr76AHgZmiht moDjnqoS7w0MDsRHyrvrUmKu7+YxSTxaD9/KB853GQNFi+fzpmviHqgELXfcOJsDf81gMCTihdl7IL dhwQ3/zQnZoHhXZiqLLXdFzoOcaKCS8o/oz92gHgzI4vcX0rwaeW6g30hkG2uuvMfI1UIp0H8pqRwX +o+yqh+aa19lMOpDLmNrsqHyA8X4Yh X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB Now that fixes for all the known issues with SME have been applied remove the BROKEN dependency from it so it's generally available again. Signed-off-by: Mark Brown Tested-By: Luis Machado --- arch/arm64/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 100570a048c5e8892c0112704f9ca74c4fc55b27..7e3182dd6fa0dadd961c352f884= 84cff0e520eaa 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2270,7 +2270,6 @@ config ARM64_SME bool "ARM Scalable Matrix Extension support" default y depends on ARM64_SVE - depends on BROKEN help The Scalable Matrix Extension (SME) is an extension to the AArch64 execution state which utilises a substantial subset of the SVE --=20 2.39.5 From nobody Fri Dec 19 18:45:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10F8420C037 for ; Wed, 4 Dec 2024 15:22:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325756; cv=none; b=rxCukOFrKNg8nEHKtGEwywS0JK3lTKdWWkaUWR4k2aRO2gdEGDptZfrIFtNBHQtSbm6WfgHoM76aWsZ9xZS7clFP2AaDIMiSdpzwo0Wa7qxa4uM/VVDMkDPs9bKgxUkrCptvDIuvD1eejD4AxgG/QpjiSc29ALoHzmwm+2546Gw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733325756; c=relaxed/simple; bh=eI1tefeXL+TZyNSuc2hjvlfnxnuJuAFK0jlaMH14RBU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Bw7CAZvo1gAVNn0qOYBfmuBkxuxgJX76CjPP3m9ofHNRhODHRoE90cRSfPTtXlaBXhqfSQqhIdPe54GZkI87m5JgA/Fvgclcb/XhvzV+PqSPyDn3jbklCEDNkh9iozzxvXtiW+hk9krFt5fXyARuK+Zt15Dgsy4WjlGb4aoqh6E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U2H5PksU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U2H5PksU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F690C4CEDF; Wed, 4 Dec 2024 15:22:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733325755; bh=eI1tefeXL+TZyNSuc2hjvlfnxnuJuAFK0jlaMH14RBU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=U2H5PksU7VxBODqWz2wkYH4LpAtnVsXX9z0m1U6UHr9xf3Mz60c2cwzBGe0OdEHeK AiJpxyx8wCcVM+GNXBDa3APp0BX7UR6/spg0ulXp2kfOp8eBcGiqp4/zalFoj2ZmaN uof4Fpe7ihF7CNTHN2HQx5NjZLF5VlSsclah/ASRl9I3L9K2cMVHxcGLvnMG28HAUH eb5FyM+2ylC9RY5vOnX/TWOtO8ixxCK+Urj0xrcl4/qaEhQw1iqZIGhVqIgyzOEpzR rRzc8vXhVFhss/etgemsRrn1Y26AG3j5GMFNecPlJj2D+JUWAzILrV11+L/IjLJDTd C7thHSskPOXQw== From: Mark Brown Date: Wed, 04 Dec 2024 15:20:54 +0000 Subject: [PATCH v2 6/6] arm64/signal: Consistently invalidate the in register FP state in restore Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20241204-arm64-sme-reenable-v2-6-bae87728251d@kernel.org> References: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> In-Reply-To: <20241204-arm64-sme-reenable-v2-0-bae87728251d@kernel.org> To: Catalin Marinas , Will Deacon Cc: Mark Rutland , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Brown X-Mailer: b4 0.15-dev-9b746 X-Developer-Signature: v=1; a=openpgp-sha256; l=7574; i=broonie@kernel.org; h=from:subject:message-id; bh=eI1tefeXL+TZyNSuc2hjvlfnxnuJuAFK0jlaMH14RBU=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBnUHOsbe0GDhU62lb7UKSWwAgaI1b1a8VR3tzw/dfD 1mu3GAGJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZ1BzrAAKCRAk1otyXVSH0KOCB/ 4p5VAQLLhXOeFnoHp6R0itwyVFkGH1spAboKblwKdR8i+wqsNaLIfICVhZ54UQPw9jtYPjjsrh9Ea0 sw9jRxJVbGL4BAy/5Msu9vVYaLkHZxOHLSCJA0eQcUIRTslxqGe6W6JpOXliPSNmckmbRgUIzv5f/h G/u6atg61wUf3tSb7goYClKr1P18RjSPc18DXBPJu0SLbv7O40nmjB44MYbkrlbkT6sSLpX2qciaL8 E/ALIsLrT5CpzQVsGxYn5KC+F64l9hr5B/2JPX0QIK3TM+iOG87JsOgcMyMXAtVT7CDOCjYHnHidmk NrfcXRH9OO26RGKlEzPPQWNigcd/O/ X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB When restoring the SVE and SME specific floating point register states we flush the task floating point state, marking the hardware state as stale so that preemption does not result in us saving register state from the signal handler on top of the restored context and forcing a reload from memory. For the plain FPSIMD state we don't do this, we just copy the state from userspace and then force an immediate reload of the register state. This isn't racy against context switch since we copy the incoming data onto the stack rather than directly into the task struct but it's still messy and inconsistent. Simplify things and avoid a potential source of error by moving the invalidation of the CPU state to the main restore_sigframe() and reworking the restore of the FPSIMD state to update the task struct and rely on loading as part of the general do_notify_resume() handling for return to user like we do for the SVE and SME state. As a result of this the only user of fpsimd_update_current_state() is the 32 bit signal code which should not have any SVE state, add an assert there that we don't have SVE enabled. Signed-off-by: Mark Brown --- arch/arm64/kernel/fpsimd.c | 9 +++--- arch/arm64/kernel/signal.c | 70 +++++++++++++++---------------------------= ---- 2 files changed, 27 insertions(+), 52 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 2b045d4d8f71ace5bf01a596dda279285a0998a5..74080204073d06819838873996b= 8cb60043d89de 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1868,7 +1868,8 @@ void fpsimd_update_current_state(struct user_fpsimd_s= tate const *state) get_cpu_fpsimd_context(); =20 current->thread.uw.fpsimd_state =3D *state; - if (test_thread_flag(TIF_SVE)) + /* This should only ever be used for 32 bit processes */ + if (WARN_ON_ONCE(test_thread_flag(TIF_SVE))) fpsimd_to_sve(current); =20 task_fpsimd_load(); @@ -1894,9 +1895,9 @@ void fpsimd_flush_task_state(struct task_struct *t) { t->thread.fpsimd_cpu =3D NR_CPUS; /* - * If we don't support fpsimd, bail out after we have - * reset the fpsimd_cpu for this task and clear the - * FPSTATE. + * If we don't support fpsimd, bail out after we have reset + * the fpsimd_cpu for this task and clear the FPSTATE. We + * check here rather than forcing callers to check. */ if (!system_supports_fpsimd()) return; diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 79c9c5cd0802149b3cde20b398617437d79181f2..335c2327baf74eac9634cf59485= 5dbf26a7d6b01 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -271,7 +271,7 @@ static int preserve_fpsimd_context(struct fpsimd_contex= t __user *ctx) =20 static int restore_fpsimd_context(struct user_ctxs *user) { - struct user_fpsimd_state fpsimd; + struct user_fpsimd_state *fpsimd =3D ¤t->thread.uw.fpsimd_state; int err =3D 0; =20 /* check the size information */ @@ -279,18 +279,14 @@ static int restore_fpsimd_context(struct user_ctxs *u= ser) return -EINVAL; =20 /* copy the FP and status/control registers */ - err =3D __copy_from_user(fpsimd.vregs, &(user->fpsimd->vregs), - sizeof(fpsimd.vregs)); - __get_user_error(fpsimd.fpsr, &(user->fpsimd->fpsr), err); - __get_user_error(fpsimd.fpcr, &(user->fpsimd->fpcr), err); + err =3D __copy_from_user(fpsimd->vregs, &(user->fpsimd->vregs), + sizeof(fpsimd->vregs)); + __get_user_error(fpsimd->fpsr, &(user->fpsimd->fpsr), err); + __get_user_error(fpsimd->fpcr, &(user->fpsimd->fpcr), err); =20 clear_thread_flag(TIF_SVE); current->thread.fp_type =3D FP_STATE_FPSIMD; =20 - /* load the hardware registers from the fpsimd_state structure */ - if (!err) - fpsimd_update_current_state(&fpsimd); - return err ? -EFAULT : 0; } =20 @@ -396,7 +392,7 @@ static int restore_sve_fpsimd_context(struct user_ctxs = *user) { int err =3D 0; unsigned int vl, vq; - struct user_fpsimd_state fpsimd; + struct user_fpsimd_state *fpsimd =3D ¤t->thread.uw.fpsimd_state; u16 user_vl, flags; =20 if (user->sve_size < sizeof(*user->sve)) @@ -439,16 +435,6 @@ static int restore_sve_fpsimd_context(struct user_ctxs= *user) if (user->sve_size < SVE_SIG_CONTEXT_SIZE(vq)) return -EINVAL; =20 - /* - * Careful: we are about __copy_from_user() directly into - * thread.sve_state with preemption enabled, so protection is - * needed to prevent a racing context switch from writing stale - * registers back over the new data. - */ - - fpsimd_flush_task_state(current); - /* From now, fpsimd_thread_switch() won't touch thread.sve_state */ - sve_alloc(current, true); if (!current->thread.sve_state) { clear_thread_flag(TIF_SVE); @@ -471,14 +457,10 @@ static int restore_sve_fpsimd_context(struct user_ctx= s *user) fpsimd_only: /* copy the FP and status/control registers */ /* restore_sigframe() already checked that user->fpsimd !=3D NULL. */ - err =3D __copy_from_user(fpsimd.vregs, user->fpsimd->vregs, - sizeof(fpsimd.vregs)); - __get_user_error(fpsimd.fpsr, &user->fpsimd->fpsr, err); - __get_user_error(fpsimd.fpcr, &user->fpsimd->fpcr, err); - - /* load the hardware registers from the fpsimd_state structure */ - if (!err) - fpsimd_update_current_state(&fpsimd); + err =3D __copy_from_user(fpsimd->vregs, user->fpsimd->vregs, + sizeof(fpsimd->vregs)); + __get_user_error(fpsimd->fpsr, &user->fpsimd->fpsr, err); + __get_user_error(fpsimd->fpcr, &user->fpsimd->fpcr, err); =20 return err ? -EFAULT : 0; } @@ -587,16 +569,6 @@ static int restore_za_context(struct user_ctxs *user) if (user->za_size < ZA_SIG_CONTEXT_SIZE(vq)) return -EINVAL; =20 - /* - * Careful: we are about __copy_from_user() directly into - * thread.sme_state with preemption enabled, so protection is - * needed to prevent a racing context switch from writing stale - * registers back over the new data. - */ - - fpsimd_flush_task_state(current); - /* From now, fpsimd_thread_switch() won't touch thread.sve_state */ - sme_alloc(current, true); if (!current->thread.sme_state) { current->thread.svcr &=3D ~SVCR_ZA_MASK; @@ -664,16 +636,6 @@ static int restore_zt_context(struct user_ctxs *user) if (nregs !=3D 1) return -EINVAL; =20 - /* - * Careful: we are about __copy_from_user() directly into - * thread.zt_state with preemption enabled, so protection is - * needed to prevent a racing context switch from writing stale - * registers back over the new data. - */ - - fpsimd_flush_task_state(current); - /* From now, fpsimd_thread_switch() won't touch ZT in thread state */ - err =3D __copy_from_user(thread_zt_state(¤t->thread), (char __user const *)user->zt + ZT_SIG_REGS_OFFSET, @@ -1028,6 +990,18 @@ static int restore_sigframe(struct pt_regs *regs, if (err =3D=3D 0) err =3D parse_user_sigframe(&user, sf); =20 + /* + * Careful: we are about __copy_from_user() directly into + * thread floating point state with preemption enabled, so + * protection is needed to prevent a racing context switch + * from writing stale registers back over the new data. Mark + * the register floating point state as invalid and unbind the + * task from the CPU to force a reload before we return to + * userspace. fpsimd_flush_task_state() has a check for FP + * support. + */ + fpsimd_flush_task_state(current); + if (err =3D=3D 0 && system_supports_fpsimd()) { if (!user.fpsimd) return -EINVAL; --=20 2.39.5