[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083B06E5B75E429E5143B76FCD39@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Mon, 30 Jan 2023 19:21:15 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: HORIGUCHI NAOYA(堀口 直也)
<naoya.horiguchi@....com>
CC: Borislav Petkov <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>,
"Li, Zhiquan1" <zhiquan1.li@...el.com>,
"Song, Youquan" <youquan.song@...el.com>
Subject: RE: [PATCH] x86/mce: Set PG_hwpoison page flag to avoid the capture
kernel panic
> Although I'm not sure that SGX memory or PMEM pages are expected to be
> included in kdump, but simply setting PageHWPoison does not work for them?
> (Maybe that depends on how kdump handles these types of memory.)
SGX/TDX pages can't be dumped. They are encrypted with no way for kdump to
get the key.
PMEM seems pointless (but I don't know what kdump does here).
> As for HugeTLB, kdump utility should parse the struct page and be aware of
> HugeTLB pages, so maybe setting PageHWPoison on the head page could work.
Or maybe kdump can take not of the PageHWPoison flag on the sub-page of the
huge page? It depends on whether there is any benefit to the dump to include the
not-poisoned parts of a huge page.
> I think that setting PageHWPoison outside hwpoison subsystem is OK here,
> because this is called just before calling panic() so it's expected to not
> conflict with other hwpoison-related code.
Thanks for the review.
-Tony
Powered by blists - more mailing lists