From: Miaohe Lin <linmiaohe@huawei.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] mce: fix missing stack-dumping in mce_panic()
Date: Mon, 9 Jan 2023 10:16:04 +0800 [thread overview]
Message-ID: <1e1bfb2a-5e20-626f-97f7-5ff4cf3d4d51@huawei.com> (raw)
In-Reply-To: <SJ1PR11MB60839243ADBEA755203CC352FCF99@SJ1PR11MB6083.namprd11.prod.outlook.com>
On 2023/1/9 1:54, Luck, Tony wrote:
>> As a first step, let's change the current behavior of no stack dumps first? And then,
>> we could try to achieve #1 preference if possible.
>
> Ok. Repost the patch that fixes things for an oops dump for every mce_panic().
Do you mean make every call site of mce_panic() does a successful oops dump? I think
this patch will have achieved that. Or do I miss-read your comment?
>
> Maybe then I can look at some way to suppress the oops dump for the "useless"
> cases? Or perhaps at least add an extra message that stack dumps from arbitrary
> machine checks are rarely useful.
IMHO the user will always expect a stack dump when system panic. I'm afraid that if these
"useless" cases are eliminated, it will cause user confused and trying to find what eats
the stack dump?
Thanks,
Miaohe Lin
next prev parent reply other threads:[~2023-01-09 2:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 16:37 [PATCH] mce: fix missing stack-dumping in mce_panic() Miaohe Lin
2022-12-02 14:44 ` Luck, Tony
2022-12-03 2:19 ` Miaohe Lin
2022-12-03 4:22 ` Tony Luck
2022-12-03 6:48 ` Miaohe Lin
2022-12-29 11:54 ` Borislav Petkov
2022-12-29 12:33 ` Miaohe Lin
2022-12-29 12:51 ` Borislav Petkov
2022-12-30 1:56 ` Miaohe Lin
2023-01-03 21:12 ` Luck, Tony
2023-01-06 1:57 ` Miaohe Lin
2023-01-06 17:42 ` Luck, Tony
2023-01-07 2:27 ` Miaohe Lin
2023-01-08 17:54 ` Luck, Tony
2023-01-09 2:16 ` Miaohe Lin [this message]
2023-01-09 4:45 ` Luck, Tony
2023-01-09 6:54 ` Miaohe Lin
2022-12-10 2:28 ` Miaohe Lin
2022-12-28 12:33 ` Miaohe Lin
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=1e1bfb2a-5e20-626f-97f7-5ff4cf3d4d51@huawei.com \
--to=linmiaohe@huawei.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).