From: Shuai Xue <xueshuai@linux.alibaba.com>
To: Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
"Luck, Tony" <tony.luck@intel.com>
Cc: nao.horiguchi@gmail.com, tglx@linutronix.de, mingo@redhat.com,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
linmiaohe@huawei.com, akpm@linux-foundation.org,
jpoimboe@kernel.org, linux-edac@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
baolin.wang@linux.alibaba.com, tianruidong@linux.alibaba.com
Subject: Re: [PATCH v2 3/5] x86/mce: add EX_TYPE_EFAULT_REG as in-kernel recovery context to fix copy-from-user operations regression
Date: Fri, 21 Feb 2025 14:52:24 +0800 [thread overview]
Message-ID: <5ff00e53-957b-4a4e-a893-f83c4995c1ed@linux.alibaba.com> (raw)
In-Reply-To: <20250219104037.GG40464@noisy.programming.kicks-ass.net>
在 2025/2/19 18:40, Peter Zijlstra 写道:
> On Tue, Feb 18, 2025 at 05:48:00PM +0100, Borislav Petkov wrote:
>> On Tue, Feb 18, 2025 at 03:15:35PM +0100, Peter Zijlstra wrote:
>>> diff --git a/arch/x86/kernel/cpu/mce/severity.c b/arch/x86/kernel/cpu/mce/severity.c
>>> index dac4d64dfb2a..cfdae25eacd7 100644
>>> --- a/arch/x86/kernel/cpu/mce/severity.c
>>> +++ b/arch/x86/kernel/cpu/mce/severity.c
>>> @@ -301,18 +301,19 @@ static noinstr int error_context(struct mce *m, struct pt_regs *regs)
>>> instrumentation_end();
>>>
>>> switch (fixup_type) {
>>> - case EX_TYPE_UACCESS:
>>> - if (!copy_user)
>>> - return IN_KERNEL;
>>> - m->kflags |= MCE_IN_KERNEL_COPYIN;
>>> - fallthrough;
>>> -
>>> case EX_TYPE_FAULT_MCE_SAFE:
>>> case EX_TYPE_DEFAULT_MCE_SAFE:
>>> m->kflags |= MCE_IN_KERNEL_RECOV;
>>> return IN_KERNEL_RECOV;
>>>
>>> default:
>>> + if (copy_user) {
>>
>> As said on chat, if we can make is_copy_from_user() *always* correctly detect
>> user access, then sure but I'm afraid EX_TYPE_UACCESS being generated at the
>> handful places where we do user memory access is there for a reason as it
>> makes it pretty explicit.
>
> Thing is, we have copy routines that do not know if its user or not.
> is_copy_from_user() must be reliable.
>
> Anyway, if you all really want to go all funny, try the below.
>
> Someone has to go and stick some EX_FLAG_USER on things, but I just
> really don't believe that's doing to be useful. Because while you're
> doing that, you should also audit if is_copy_from_user() will catch it
> and if it does, you don't need the tag.
>
> See how much tags you end up with..
Agreed, I think the key point whether the error context is in a read from user
memory. We do not care about the ex-type if we know its a MOV
reading from userspace.
is_copy_from_user() return true when both of the following two checks are
true:
- the current instruction is copy
- source address is user memory
If copy_user is true, we set
m->kflags |= MCE_IN_KERNEL_COPYIN | MCE_IN_KERNEL_RECOV;
Then do_machine_check will try fixup_exception first.
/*
* Handle an MCE which has happened in kernel space but from
* which the kernel can recover: ex_has_fault_handler() has
* already verified that the rIP at which the error happened is
* a rIP from which the kernel can recover (by jumping to
* recovery code specified in _ASM_EXTABLE_FAULT()) and the
* corresponding exception handler which would do that is the
* proper one.
*/
if (m->kflags & MCE_IN_KERNEL_RECOV) {
if (!fixup_exception(regs, X86_TRAP_MC, 0, 0))
mce_panic("Failed kernel mode recovery", &err, msg);
}
if (m->kflags & MCE_IN_KERNEL_COPYIN)
queue_task_work(&err, msg, kill_me_never);
So Peter's code is fine to me.
---
diff --git a/arch/x86/kernel/cpu/mce/severity.c b/arch/x86/kernel/cpu/mce/severity.c
index dac4d64dfb2a..cb021058165f 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_COPYIN;
+ 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;
Is that ok? Please correct me if I missed anyting.
Thanks.
Shuai
next prev parent reply other threads:[~2025-02-21 6:52 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 6:33 [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure handling Shuai Xue
2025-02-17 6:33 ` [PATCH v2 1/5] x86/mce: Collect error message for severities below MCE_PANIC_SEVERITY Shuai Xue
2025-02-18 7:58 ` Borislav Petkov
2025-02-18 9:39 ` Shuai Xue
2025-02-18 9:50 ` Borislav Petkov
2025-02-17 6:33 ` [PATCH v2 2/5] x86/mce: dump error msg from severities Shuai Xue
2025-02-28 12:37 ` Borislav Petkov
2025-03-01 6:16 ` Shuai Xue
2025-03-01 11:10 ` Borislav Petkov
2025-03-01 14:03 ` Shuai Xue
2025-03-01 18:47 ` Borislav Petkov
2025-03-02 7:14 ` Shuai Xue
2025-03-02 7:37 ` Borislav Petkov
2025-03-02 9:13 ` Shuai Xue
2025-03-03 16:49 ` Luck, Tony
2025-03-03 18:08 ` Yazen Ghannam
2025-03-05 1:50 ` Shuai Xue
2025-03-05 16:16 ` Luck, Tony
2025-03-05 22:33 ` Luck, Tony
2025-03-06 15:58 ` Yazen Ghannam
2025-02-17 6:33 ` [PATCH v2 3/5] x86/mce: add EX_TYPE_EFAULT_REG as in-kernel recovery context to fix copy-from-user operations regression Shuai Xue
2025-02-18 12:54 ` Peter Zijlstra
2025-02-18 13:02 ` Peter Zijlstra
2025-02-18 14:03 ` Shuai Xue
2025-02-18 13:28 ` Shuai Xue
2025-02-18 14:15 ` Peter Zijlstra
2025-02-18 16:48 ` Borislav Petkov
2025-02-19 10:40 ` Peter Zijlstra
2025-02-21 6:52 ` Shuai Xue [this message]
2025-02-17 6:33 ` [PATCH v2 4/5] mm/hwpoison: Fix incorrect "not recovered" report for recovered clean pages Shuai Xue
2025-02-19 6:34 ` Miaohe Lin
2025-02-19 8:54 ` Shuai Xue
2025-02-19 17:15 ` Luck, Tony
2025-02-20 1:16 ` Miaohe Lin
2025-02-17 6:33 ` [PATCH v2 5/5] mm: memory-failure: move return value documentation to function declaration Shuai Xue
2025-02-19 6:31 ` Miaohe Lin
2025-02-18 3:29 ` [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure handling Andrew Morton
2025-02-18 8:03 ` Borislav Petkov
2025-02-18 8:27 ` Borislav Petkov
2025-02-18 11:31 ` Shuai Xue
2025-02-18 12:24 ` Borislav Petkov
2025-02-18 13:08 ` Shuai Xue
2025-02-18 13:17 ` Borislav Petkov
2025-02-18 13:53 ` Shuai Xue
2025-02-18 15:31 ` Borislav Petkov
2025-02-19 7:13 ` Shuai Xue
2025-02-18 17:59 ` Luck, Tony
2025-02-19 6:04 ` Shuai Xue
2025-02-18 17:30 ` Luck, Tony
2025-02-19 8:10 ` Borislav Petkov
2025-02-19 17:11 ` Luck, Tony
2025-02-20 11:19 ` Borislav Petkov
2025-02-20 17:50 ` Luck, Tony
2025-02-21 6:05 ` Shuai Xue
2025-02-24 22:01 ` Borislav Petkov
2025-02-25 1:51 ` Shuai Xue
2025-02-28 12:35 ` Borislav Petkov
2025-03-01 5:54 ` Shuai Xue
2025-02-24 21:50 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5ff00e53-957b-4a4e-a893-f83c4995c1ed@linux.alibaba.com \
--to=xueshuai@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=nao.horiguchi@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tianruidong@linux.alibaba.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.