[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB60830CE8C3F79C9531C8567AFC179@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 2 Dec 2022 14:44:00 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Miaohe Lin <linmiaohe@...wei.com>, "bp@...en8.de" <bp@...en8.de>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC: "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] mce: fix missing stack-dumping in mce_panic()
> When machine check exception occurs, there is no stack-dumping now in
> mce_panic(). It's because bust_spinlocks(1) is called prematurely so
> oops_in_progress will be >= 2 when trying to call dump_stack() in
> panic(). Thus dump_stack() won't be called as this is considered as
> nested stack-dumping.
I had an earlier patch series to just dump from "interesting" machine checks
(I think the interesting ones are when the kernel hit poison in code that hadn't
been tagged in the extable as recoverable)
https://lore.kernel.org/all/20220922195136.54575-1-tony.luck@intel.com/
Discussion on that fizzled out.
Thanks for tracking down why panic() didn't provide a stack dump.
I'm still of the opinion that stack dumps from machine checks aren't
generally useful. But I'd rather have extra stack dumps than no stack
dumps at all.
-Tony
Powered by blists - more mailing lists