[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB60830F499CB509A1262C745BFCD6A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Tue, 17 Oct 2023 17:35:02 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Li, Zhiquan1" <zhiquan1.li@...el.com>,
Borislav Petkov <bp@...en8.de>
CC: "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>,
"mingo@...nel.org" <mingo@...nel.org>,
"naoya.horiguchi@....com" <naoya.horiguchi@....com>
Subject: RE: [PATCH v3] x86/mce: Set PG_hwpoison page flag to avoid the
capture kernel panic
> Tony, your commit message made me realize how verbose my commit message
> is. May I simplify the whole commit message as following for next version?
>
> ---start---
> Memory errors don't happen very often, especially the severity is fatal.
> However, in large-scale scenarios, such as data centers, it might still
> happen. When there is a fatal machine check Linux calls mce_panic()
> without checking to see if bad data at some memory address
> was reported in the machine check banks.
>
> If kexec is enabled, check for memory errors and mark the page as
> poisoned so that the kexec'ed kernel can avoid accessing the page.
> ---end---
>
> It already covers the scenario, root cause and solution, and focuses on
> kernel. No need to talk something else.
Yes, you can use that. Being concise (but keeping the important details)
is the art of a good commit message.
-Tony
Powered by blists - more mailing lists