From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 343FB2AF16 for ; Wed, 8 Jan 2025 02:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736303858; cv=none; b=h59MGNc/zRH5U6woc4h3NaLQZzmn9KX+8f5yPkrqs2leATwGHXj51nD9ohEt8/Lwx8x96NmfFWbsJRFHlAHrYo6yDiJBHTHcDKz/kLWgMpFRbdg7a3KBBOBIwZLGXL46//0Iv5xTJqTaAugEuwp/93TTPzz95Unm4eStLoFFGSI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736303858; c=relaxed/simple; bh=MEB0WCPRKtsYUQ4slNTb00bFAOkarJFnNQp6EmcN00E=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=US9MJkmlNhHFordGR0eOUOj/YRGD1DdkAzQxrRWcQL0Dne9FbK0J/lW2qd02zUvnuZb9R5EpVbvPQhzwp1LraU2yD4PiGWka4Hx+eYpWWhM+hYU6GK011GEl2bcH9f0sfvnbDgjLWjIuzmHheNxUSZxhPQ0K5my/Gmyr+LBqLA8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=zckWRgMt; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="zckWRgMt" Received: from terminus.zytor.com (terminus.zytor.com [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 5082agt5017408 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 7 Jan 2025 18:36:45 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 5082agt5017408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024121701; t=1736303806; bh=vpafHqbsuB0isqhUALlfuxeMPiBqWpS9eXd0NV6UbBM=; h=From:To:Cc:Subject:Date:From; b=zckWRgMtAr5vPrQrXlpTa7SGJwT+ZHNnwgb7UrboyWOXhX6+GJWskg3X0KD2wi5Vu u0D6LvA4GLwwX2DS1faTVqnJM7rpugs4/yn8q0U1KhShp/2lDQZ8r9jqGPVd4sozT+ ZE3Bo5bU6SSjuS5oi2Y2KF8Ec3QIMChxBxP/vLNVBEGL8T/LBHX+06A3v6KBO8vchb SSObztd056PdyUTMSUDOmi8UCfWdnNOs/ZElXdj20+xlVDLMBv/w9fUP7E+FmC5ukl 6kIlZHuWMAhHf2SF7JO4FEZtRRC4gzLJq3HPaXVvhSDaNyrp8xuutB2m+20xA1Tqq7 fHqjaVmy1FhGQ== From: "Xin Li (Intel)" To: linux-kernel@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, andrew.cooper3@citrix.com Subject: [PATCH v1 1/1] x86/fred: Fix the FRED RSP0 MSR out of sync with its per CPU cache Date: Tue, 7 Jan 2025 18:36:41 -0800 Message-ID: <20250108023641.17396-1-xin@zytor.com> X-Mailer: git-send-email 2.47.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The FRED RSP0 MSR (pointing to the top of the kernel stack for user level event delivery) and its per CPU cache should be kept in sync to avoid redundant writes in the exit to user space path, as a result, a write to the FRED RSP0 MSR is paired with a write to its per CPU cache as fred_update_rsp0() does. However as the FRED RSP0 MSR is set to 0 in cpu_init_fred_exceptions(), it gets out of sync with its per CPU cache during a CPU offline/online cycle, which causes #DF exceptions if no context switch happens after a CPU offline/online cycle and before exit to user space. Fix the bug through resynchronizing the FRED RSP0 MSR with its per CPU cache value in cpu_init_fred_exceptions(). Fixes: fe85ee391966 ("x86/entry: Set FRED RSP0 on return to userspace instead of context switch") Signed-off-by: Xin Li (Intel) Cc: stable@vger.kernel.org --- arch/x86/kernel/fred.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c index 8d32c3f48abc..9524ace96bfa 100644 --- a/arch/x86/kernel/fred.c +++ b/arch/x86/kernel/fred.c @@ -50,7 +50,18 @@ void cpu_init_fred_exceptions(void) FRED_CONFIG_ENTRYPOINT(asm_fred_entrypoint_user)); wrmsrl(MSR_IA32_FRED_STKLVLS, 0); - wrmsrl(MSR_IA32_FRED_RSP0, 0); + + /* + * Resynchronize the FRED RSP0 MSR with its per CPU cache value. + * + * Another option is to leave the FRED RSP0 MSR as-is, because the RESET + * state of FRED MSRs is zero and INIT does not change the value of the + * FRED MSRs in a CPU offline/online cycle. But it doesn't seem safe to + * depend on the properties of INIT as that's way too many things that + * could cause bugs. + */ + wrmsrl(MSR_IA32_FRED_RSP0, __this_cpu_read(fred_rsp0)); + wrmsrl(MSR_IA32_FRED_RSP1, 0); wrmsrl(MSR_IA32_FRED_RSP2, 0); wrmsrl(MSR_IA32_FRED_RSP3, 0); base-commit: cf6b067860f69fe01b08ebae9138fe0f89854398 -- 2.47.1