From nobody Mon Feb 9 02:27:24 2026 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 19C0D217657; Wed, 30 Oct 2024 20:49:49 +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=1730321390; cv=none; b=WG2VXiwaxbbwosJh1pIWlXlkL91hXjTWN7fv3tmKi54IrZAqhIW8UH+5XmBKgzjFBuxDCWzhR0Olass18UgTLINH2ptj8ZJGIm4tO1jV4F8LSMEdaMJ+6LMfxq+PKDRqlOuddSs2D/FHwfgYJ5CuvLa98AHD1gVv0YToLKOmlOs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730321390; c=relaxed/simple; bh=qJdTcgpxMWoOYJiUsP4GiG9tUqa01DGZ7YOgoBaVGYE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=KBJTV7YStkqSp7imVksZwabPkiicylrpWYbjBsoYbMgQ1tHM3CBxzdK+lf4vQRIGXRCFZNK8XiCUofvKuCPCLsCIJ9ykUI8B3nG8g6e2eAaJc53OIPTm3hQDU0VO6kSg71sm/ATEqIIwR9qfM6438eeZhIr1A+fRDZ/4Jg4B0rQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MOoVF7LL; 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="MOoVF7LL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2757FC4CED3; Wed, 30 Oct 2024 20:49:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730321389; bh=qJdTcgpxMWoOYJiUsP4GiG9tUqa01DGZ7YOgoBaVGYE=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=MOoVF7LLTAGPZR8k2y9yUPTSo3ePcHSsIQKKysT8QUfGtY3lQVdYZqVM+iITuloim E7+DHneXNINFM3j7VlFWRmnGc3PyugIbOXZn3HOW5OuZ+JTup64mFLx/RYvpVC3tYd 46qFpapz61zxbnJQTiIH6BJB/ix0X5AZ2cd0ZR6SruXvngyNixxOHkgHgN2JDjbyQf 40BTfLzImQ7zA6ViT1dH8CjN8RBP++xbxwf/3fDZv7B7xB5oWn9brXkpUrV9lo91xN QODVwZPQJYvp165YgXvA8QAIdZ2SQlJXRTlygDB0e7HeyskrYT+kV6ScZTOyMBtuid Y6zZhINpalTnw== From: Mark Brown Date: Wed, 30 Oct 2024 20:23:51 +0000 Subject: [PATCH 2/2] 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: <20241030-arm64-fpsimd-foreign-flush-v1-2-bd7bd66905a2@kernel.org> References: <20241030-arm64-fpsimd-foreign-flush-v1-0-bd7bd66905a2@kernel.org> In-Reply-To: <20241030-arm64-fpsimd-foreign-flush-v1-0-bd7bd66905a2@kernel.org> To: Catalin Marinas , Will Deacon Cc: Mark Rutland , 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=1522; i=broonie@kernel.org; h=from:subject:message-id; bh=qJdTcgpxMWoOYJiUsP4GiG9tUqa01DGZ7YOgoBaVGYE=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBnIpvnUTblL/oeizk6bN46HjZA0iw8vzEUtYmdpw9l fgVjsx+JATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZyKb5wAKCRAk1otyXVSH0O0ZB/ 9Y9TutGjpVTwnaB7MGwyaYlS45T1zetmUTPlUgk5Bzrrtxnik4kWCWtMbUweX/06JhukK8Mo25LHu+ IWlwyj0MO9SREDJUnqgGsAeJwCLx+Zg1mduJpZynDnFSwuCdEPM2cWtUu+LMvmG5MM05wquiL96F6Y EoQ50JgPqJV3ssrk+StMixv8AsUsRJ3EcECzuWQF34WlHFILUocL7cTz1i1yP5T3ykAQy0dy/knPu3 wg1GhMzCp7m1ouVUHjLlJOSHBZjzO7KwS+fjTjDJU3zO5K/oSwd70BUm/CVBykNnZDDaafQnleB30X pMa33MLb0Sh+c5uvS/mgWDsXmFUW/H 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 6d21971ae5594f32947480cfa168db400a69a283..1eaa670cbffa448c1aced8c8b37= 040492e18a21f 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.2