[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250312112852.82415-2-xueshuai@linux.alibaba.com>
Date: Wed, 12 Mar 2025 19:28:50 +0800
From: Shuai Xue <xueshuai@...ux.alibaba.com>
To: akpm@...ux-foundation.org,
linmiaohe@...wei.com,
nao.horiguchi@...il.com
Cc: tony.luck@...el.com,
bp@...en8.de,
peterz@...radead.org,
catalin.marinas@....com,
yazen.ghannam@....com,
tglx@...utronix.de,
mingo@...hat.com,
dave.hansen@...ux.intel.com,
x86@...nel.org,
hpa@...or.com,
jpoimboe@...nel.org,
linux-edac@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
baolin.wang@...ux.alibaba.com,
tianruidong@...ux.alibaba.com,
xueshuai@...ux.alibaba.com
Subject: [PATCH v4 1/3] x86/mce: Use is_copy_from_user() to determine copy-from-user context
Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new
extable fixup type, EX_TYPE_EFAULT_REG, and commit 4c132d1d844a
("x86/futex: Remove .fixup usage") updated the extable fixup type for
copy-from-user operations, changing it from EX_TYPE_UACCESS to
EX_TYPE_EFAULT_REG. The error context for copy-from-user operations no
longer functions as an in-kernel recovery context. Consequently, the error
context for copy-from-user operations no longer functions as an in-kernel
recovery context, resulting in kernel panics with the message: "Machine
check: Data load in unrecoverable area of kernel."
To address this, it is crucial to identify if an error context involves a
read operation from user memory. The function is_copy_from_user() can be
utilized to determine:
- the current operation is copy
- when reading user memory
When these conditions are met, is_copy_from_user() will return true,
confirming that it is indeed a direct copy from user memory. This check is
essential for correctly handling the context of errors in these operations
without relying on the extable fixup types that previously allowed for
in-kernel recovery.
So, use is_copy_from_user() to determine if a context is copy user directly.
Fixes: 4c132d1d844a ("x86/futex: Remove .fixup usage")
Suggested-by: Peter Zijlstra <peterz@...radead.org>
Signed-off-by: Shuai Xue <xueshuai@...ux.alibaba.com>
Acked-by: Borislav Petkov (AMD) <bp@...en8.de>
Tested-by: Tony Luck <tony.luck@...el.com>
Cc: stable@...r.kernel.org
---
arch/x86/kernel/cpu/mce/severity.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/severity.c b/arch/x86/kernel/cpu/mce/severity.c
index dac4d64dfb2a..2235a7477436 100644
--- a/arch/x86/kernel/cpu/mce/severity.c
+++ b/arch/x86/kernel/cpu/mce/severity.c
@@ -300,13 +300,12 @@ static noinstr int error_context(struct mce *m, struct pt_regs *regs)
copy_user = is_copy_from_user(regs);
instrumentation_end();
- switch (fixup_type) {
- case EX_TYPE_UACCESS:
- if (!copy_user)
- return IN_KERNEL;
- m->kflags |= MCE_IN_KERNEL_COPYIN;
- fallthrough;
+ if (copy_user) {
+ m->kflags |= MCE_IN_KERNEL_COPYIN | MCE_IN_KERNEL_RECOV;
+ return IN_KERNEL_RECOV;
+ }
+ switch (fixup_type) {
case EX_TYPE_FAULT_MCE_SAFE:
case EX_TYPE_DEFAULT_MCE_SAFE:
m->kflags |= MCE_IN_KERNEL_RECOV;
--
2.39.3
Powered by blists - more mailing lists