From mboxrd@z Thu Jan 1 00:00:00 1970 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 6D79E22331F; Thu, 12 Dec 2024 17:11:45 +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=1734023505; cv=none; b=FFT4HQgItZHr6Nxy2c0M1AVY4EhBd7mkPkOmWgSiMdtE8gIFnc8InE8mHN1cI55lb3+K0JTBcfBbA+S3vIzJwl1Y3k7YDTibCO3zQz7YpEERLM+JECfd/3zT2PygiIFfrPf0iAa+NGP+0peC2V4qGeykZNW0TFCXlhNsf/ncNdU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734023505; c=relaxed/simple; bh=KPVgUedjrMapwfSaBnV/rYPUgXeET78+AzqtY2vKL7g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uNEPs5GmfR5Pt+6nBFjSGH7zvcScG5+WRYgsNxQIxwNVj/MZ/2DA6ANOF51IPfZcWB02Zfl3xektaKlg/Wza126Pa2Cxv/ARcyg2KPZdmK5YYrVf73oKuvnLzPjq/MFmc7LpzjbEPjL0ppfrTGRxmBdtK3dvm1ygFsF0aRKE8iQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=v+N6W/1r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="v+N6W/1r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0005C4CED0; Thu, 12 Dec 2024 17:11:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1734023505; bh=KPVgUedjrMapwfSaBnV/rYPUgXeET78+AzqtY2vKL7g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v+N6W/1rlh0120k36v/0dPO0kLFwWbqhGJoCDd42tZAaFiYRmRWt5qTCkn4+QqKPY xqw4T6N4XPOiTaMMGkeh6/neaAqyvFlRp1yJMtzNeAaD0WkDBcnMgnABsttKZ0Xi5S y73zuYRdjVLuK8+D+8yqoEnwQgjCFStH0F2FrpVI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Mark Rutland , Mark Brown , Will Deacon Subject: [PATCH 5.15 556/565] arm64/sve: Discard stale CPU state when handling SVE traps Date: Thu, 12 Dec 2024 16:02:31 +0100 Message-ID: <20241212144333.840993605@linuxfoundation.org> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241212144311.432886635@linuxfoundation.org> References: <20241212144311.432886635@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mark Brown commit 751ecf6afd6568adc98f2a6052315552c0483d18 upstream. The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Fixes: cccb78ce89c4 ("arm64/sve: Rework SVE access trap to convert state in registers") Reported-by: Mark Rutland Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Reviewed-by: Mark Rutland Link: https://lore.kernel.org/r/20241030-arm64-fpsimd-foreign-flush-v1-1-bd7bd66905a2@kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman --- arch/arm64/kernel/fpsimd.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -964,6 +964,7 @@ void do_sve_acc(unsigned long esr, struc fpsimd_bind_task_to_cpu(); } else { fpsimd_to_sve(current); + fpsimd_flush_task_state(current); } put_cpu_fpsimd_context();