From: Borislav Petkov <bp@alien8.de>
To: Andrew Zaborowski <andrew.zaborowski@intel.com>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Eric Biederman <ebiederm@xmission.com>,
"x86@kernel.org" <x86@kernel.org>, Tony <tony.luck@intel.com>,
Andrew Zaborowski <balrogg@gmail.com>
Subject: Re: [RESEND][PATCH 1/3] x86: Add task_struct flag to force SIGBUS on MCE
Date: Sat, 10 Aug 2024 05:21:49 +0200 [thread overview]
Message-ID: <20240810032134.GAZrbcvpn_cYzFdEwB@fat_crate.local> (raw)
In-Reply-To: <CAOq732KnHFo3VaRH9V-x0k5m=h1jyNrdtKj4quG8Yaq7wPQjKg@mail.gmail.com>
On Sat, Aug 10, 2024 at 03:20:10AM +0200, Andrew Zaborowski wrote:
> True, though that's hard to link to a specific process crash.
The process name when the MCE gets reported is *actually* there in the
splat: current->comm.
> I was replying to your comment about the size of the change.
My comment was about the code you're adding:
arch/x86/kernel/cpu/mce/core.c | 18 +++++++++++++++++-
fs/exec.c | 15 ++++++++++++---
include/linux/sched.h | 2 ++
kernel/rseq.c | 25 +++++++++++++++++++++----
4 files changed, 52 insertions(+), 8 deletions(-)
If it is in drivers, I don't care. But it is in main paths and for
a questionable use case.
> Supporting something generally includes supporting the common and the
> obscure cases.
Bullshit. We certainly won't support some obscure use cases just
because.
> From the user's point of view the kernel has been committed to
> supporting these scenarios indefinitely or until the deprecation of
> the SIGBUS-on-memory-error logic, and simply has a bug.
And lemme repeat my question:
So why does it matter if a process which is being executed and gets an
MCE beyond the point of no return absolutely needs to return SIGBUS vs
it getting killed and you still get an MCE logged on the machine, in
either case?
Bug which is seen by whom or what?
If a process dies, it dies.
> In these tests the workload was simply relaunched on a SIGBUS which
> sounded fair to me. A qemu VM could similarly be restarted on an
> unrecoverable MCE in a page that doesn't belong to the VM but to qemu
> itself.
If an MCE hits at that particular point once in a blue moon, I don't
care. If it is a special use case where you inject an MCE right then and
there to test recovery actions, then that's perhaps a different story.
Usually, a lot of things can be done. As long as there's a valid use
case to support. But since you hesitate to explain what exactly we're
supporting, I can't help you.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2024-08-10 3:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 14:47 Andrew Zaborowski
2024-07-23 14:47 ` [RESEND][PATCH 2/3] execve: Ensure SIGBUS delivered on memory failure Andrew Zaborowski
2024-07-23 14:47 ` [RESEND][PATCH 3/3] rseq: " Andrew Zaborowski
2024-08-06 4:37 ` Kees Cook
2024-08-06 7:51 ` Peter Zijlstra
2024-08-06 14:19 ` Mathieu Desnoyers
2024-08-06 4:36 ` [RESEND][PATCH 1/3] x86: Add task_struct flag to force SIGBUS on MCE Kees Cook
2024-08-06 8:35 ` Borislav Petkov
[not found] ` <SA1PR11MB69926BFE8EFDA7B3C3D84560E7B82@SA1PR11MB6992.namprd11.prod.outlook.com>
[not found] ` <CAOq732KXwsKdht55E-Z18choiAYn6dMpXc-TD15B7MOUH1fpxQ@mail.gmail.com>
[not found] ` <20240808145331.GAZrTb60FX_I3p0Ukx@fat_crate.local>
2024-08-09 1:22 ` Andrew Zaborowski
2024-08-09 8:34 ` Borislav Petkov
[not found] ` <SA1PR11MB69927AE28B46583DCB5C97DEE7BA2@SA1PR11MB6992.namprd11.prod.outlook.com>
2024-08-10 1:20 ` Andrew Zaborowski
2024-08-10 3:21 ` Borislav Petkov [this message]
2024-08-10 3:55 ` Andrew Zaborowski
2024-08-10 9:25 ` 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=20240810032134.GAZrbcvpn_cYzFdEwB@fat_crate.local \
--to=bp@alien8.de \
--cc=andrew.zaborowski@intel.com \
--cc=balrogg@gmail.com \
--cc=ebiederm@xmission.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox