From nobody Fri Dec 19 20:15:42 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