Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Message-ID: <3f9e9468-ec74-42ad-8d42-c3f6fb8b5f74@intel.com>
Date:   Wed, 11 Oct 2023 11:00:57 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH RESEND v2] x86/mce: Set PG_hwpoison page flag to avoid the
 capture kernel panic
Content-Language: en-US
To:     Borislav Petkov <bp@alien8.de>
CC:     <x86@kernel.org>, <linux-edac@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <patches@lists.linux.dev>,
        <tony.luck@intel.com>, <naoya.horiguchi@nec.com>
References: <20230914030539.1622477-1-zhiquan1.li@intel.com>
 <20231010082836.GDZSULNGto0cPRPU26@fat_crate.local>
From:   Zhiquan Li <zhiquan1.li@intel.com>
In-Reply-To: <20231010082836.GDZSULNGto0cPRPU26@fat_crate.local>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z1VFbHFUTTV5ejgySkZKZGVzbXJESWJFMzhSR3QvSDZaaU5ZR0V4YXo2a0NB?=
 =?utf-8?B?cXRwYWVRdHM5QTBESEcyQXdDeWhxZmNsYVhqN2lFVWt6TklhMUFwWVFlSjls?=
 =?utf-8?B?Mi92Zm0zaDNxNGlLeE5KWEpWWW1hK3d2MVpjL1hsTFRsaTUzLzBoTkY1YzdB?=
 =?utf-8?B?SXo5NnJ2M3hHWnhjTEZ3RTlQVytlSGo5bTlFZjRBOWhWL2tkLzBpencwM2wy?=
 =?utf-8?B?ekdTelRMdWl4MGlTUWsyN1JCVG1Ib3JnOUxwajRKd2haMVd2WlV4dkw0R1dh?=
 =?utf-8?B?Q3N3cXh1ZlQ1eExjMVVsWC9IcHFvNUd1aDU4WDQ2ZXlHWkxyYi8wTFRSYURu?=
 =?utf-8?B?d3ExeFVpQmlaY0tIbEVNdlNoV0hzYkhkaFBIYi96VDBSbXhoTlArUkRqVVZZ?=
 =?utf-8?B?c0NnTXVrY2JnR21Cc2Z5NC9GOWs4QkZuNlNybVZNYmJaVzRldk5XU1ZBY2Zm?=
 =?utf-8?B?eTRHcng1NXFvVDNDakJHR2NRN3dWN1FJT0hxK0Y5cG1RMml5b09GZ3VMekE0?=
 =?utf-8?B?Tk5NUnUrTStlT2NOVDBWOVBicE1RbnBWSDhaWDFBbkxGWDVZUnpSNlV0UWo1?=
 =?utf-8?B?UzhnREgzT2x3bUNaTFVUM25lS1R0U3FwWWYzOGludDIyT3FuOXhqTnRWWHZp?=
 =?utf-8?B?TzQ5NVhaT0pRTmVnNncvczNUM3AwdzEwZjJKR1RYeFBVaGx1c28wVlRJYSth?=
 =?utf-8?B?TzQxcFR4eUVmQjF6dFJibStnQzZxSVhwY3BoNVFndy9zOHNhbDRvOSswR0lq?=
 =?utf-8?B?cnAxZUliV3A0b1pHOHBIaDM3aU5iU3Vhb3gxVTdjVFl3RlVZRDlWektwOXlB?=
 =?utf-8?B?QjV5cVRHZHlDS2R2M1c2QzZSWFA1aC9vNDd6em5WakwwU2IzZDZoTUNZckJo?=
 =?utf-8?B?VEtLWDVIT3NzekZvZmIvMzZZempEZkFFSXVBZzRvSEI4WnlKNVhlQndPU21N?=
 =?utf-8?B?bEZoZ0o1NFJOWGNLOE9KUWlwQTE5cldsQ1dkT0NCVit3ajZkSEFURFlha1BT?=
 =?utf-8?B?dVZZZWZ1UkFleEFlVEdtczloWjdwem9nY1c2a1ByTnRqbzMyTklUUUJUalpn?=
 =?utf-8?B?b0U3b1o3bnlwRml2aFNBYTVPaG12Wk1jaE9ibERlMWw5REJXbXZCVUJLYW00?=
 =?utf-8?B?Nkx3MWRDRXFENndCMVJDTGFxcXZycWNJNGpIcVJwNnMzT3dJdkk3N1JxVkxF?=
 =?utf-8?B?UCtvVnk1YThXSTBVb0pkYU9pVkMwL1MvNlB3L2k5SktFTEg0UDUyc3BJU0Jz?=
 =?utf-8?B?OHlMZVJlRC8xcUt6S3JOYW5Zb1B5NWdzNnVMQnE3VklIZnVxR0s3UXBXOTVP?=
 =?utf-8?B?Y0QxR0I0bkl3WXJqRjhibGprTHY3NDBUMElDOGVEamZyanJCcnF6ZE9tMTdk?=
 =?utf-8?B?bEdvbFBscEQvNWJEWHV6TWdJeTF3OUxhZHpvYWQ3RUJxT25mUlc3bFRtSnQx?=
 =?utf-8?B?eldJLzYvK3ArWTN3YzlDWnhIcEVZVlRUYmd2Qld0dlFPWGt5czdrU0o3Uytx?=
 =?utf-8?B?YysrQThXOExaZ2hJWGxtQ0JQSVZmUkhLcDRoZEpGZVdvSzh1TDUzWThrVFVT?=
 =?utf-8?B?c3NzSmJkZG1MUWVCYmhBOU40a0RIbjkxRGllenozcGZNZ0lnQ1JMM3NDN3RN?=
 =?utf-8?B?TUhuK3dsd2pTblBpZXZESmI0Mlo2ZG1tT1Z2WVVzaWxYKysxaGErcjJjd2tt?=
 =?utf-8?B?ZHZDNUMzQjRib3ZwLzdRUUF5Y1ZUODJreThJTEJwV1R6VXBKMFlTaDRSNnBS?=
 =?utf-8?B?L3Joc2hjWXJTTHJxbHBrNHpTaExqdXMvN0U4TFdrdnowcGFPNXgrRFJodFFk?=
 =?utf-8?B?NEg1YkZITHVjZlBnT0NxYlFBYVhuSTRhcUZ3VjJBSTIxRjZsZ3Z5djFNOHQr?=
 =?utf-8?B?S3ZPNmczV2RCbUtLNzVlWHEzaGQ4T09NZUs5MS9Bblh0UGJRWmxXRE1kWjk0?=
 =?utf-8?B?Z3MzeDcwT1NvSlNxNnJ1Yy9YUCtkZkhPVkFUMk04THdBekVvajZZL2cxNG1r?=
 =?utf-8?B?WHRVNXFUbFhPQW5oTUMvT2xXblo3eDBLb1FBOXB1ZjdqTURqWnpxMXJaQzYz?=
 =?utf-8?B?YzRqZ3pjc2g2YThPN3BrTUdSWWZUNEVQOWo3UXJObkNOVGRLYmtsR0IzeG4r?=
 =?utf-8?Q?0iQE3HKybzEcKSXLHnqsB4672?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 36f32d8b-2243-4b9f-3f5f-08dbca03a3ea
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3728.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2023 02:41:59.7696
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /Cz1s6m7m78a4SSB3Rg8iiBM9M70ZT4X0QK4WKhNyM7krVPvVRwowToK1HaTQIdmRSXWf4A9NHoczI8LuL7usw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB6994
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,
	URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 10 Oct 2023 19:42:29 -0700 (PDT)
X-Spam-Level: **


On 2023/10/10 16:28, Borislav Petkov wrote:
> This commit message should explain the full scenario, like you did in
> your other reply.
> 

Thanks for your review, Boris!

I'll improve the commit message in V3 as you said.  Just adding the full
scenario part, the paragraphs to introduce the considerations for the 3
solutions and how to validate the patch are unnecessary, right?

> Also explain how the poison flag is consumed by the kdump kernel and put
> that in the comment below.
> 

Aha, this is the neat thing about the patch.  The main task of kdump
kernel is providing a "window" - /proc/vmcore, for the dump program to
access old memory.  A dump program running in userspace determines the
"policy".  Which pages need to be dumped is determined by the
configuration of dump program, it reads out the pages that the
sustaining engineer is interested in and excludes the rest.  The de
facto dump program (makedumpfile) already supports to identify those
poisoned pages and exclude them a decade ago:

https://github.com/makedumpfile/makedumpfile/commit/030800d88d4baca5f60ade0acc1846a65608883c

That's why I said the solution 1 is remaking the wheels, scanning MCE
banks, checking the poison flag, and excluding error pages are
duplicated actions.  To set the HWPosion flag in the production kernel
before panics is the only missing step to make everything work.


>> [Tony: Changed TestSetPageHWPoison() to SetPageHWPoison()]
>>
>> Co-developed-by: Youquan Song <youquan.song@intel.com>
>> Signed-off-by: Youquan Song <youquan.song@intel.com>
>> Signed-off-by: Zhiquan Li <zhiquan1.li@intel.com>
>> Signed-off-by: Tony Luck <tony.luck@intel.com>
> What does Tony's SOB mean here?
> 
> If I read it correctly, it is him sending this patch now. But you're
> sending it so you folks need to read up on SOB chains.
> 

When we were developing the patch internally, Tony contributed a lot of
precious ideas and guidance, not only the code change he mentioned in
commit message.

The previous V2 sent by Tony missed the merge window of v6.5, so I
re-based it onto the latest v6.6 rc, re-validated and re-send the patch.
 And I will follow up the feedback from community.


>> Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
>>
>> ---
>> V2 RESEND notes:
>> - No changes on this, just rebasing as v6.6-rc1 is out.
>> - Added the tag from Naoya.
>>   Link: https://lore.kernel.org/all/20230719211625.298785-1-tony.luck@intel.com/#t
>>
>> Changes since V1:
>> - Revised the commit message as per Naoya's suggestion.
>> - Replaced "TODO" comment in code with comments based on mailing list
>>   discussion on the lack of value in covering other page types.
>>   Link: https://lore.kernel.org/all/20230127015030.30074-1-tony.luck@intel.com/
>> ---
>>  arch/x86/kernel/cpu/mce/core.c | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
>> index 6f35f724cc14..2725698268f3 100644
>> --- a/arch/x86/kernel/cpu/mce/core.c
>> +++ b/arch/x86/kernel/cpu/mce/core.c
>> @@ -156,6 +156,22 @@ void mce_unregister_decode_chain(struct notifier_block *nb)
>>  }
>>  EXPORT_SYMBOL_GPL(mce_unregister_decode_chain);
>>  
>> +/*
>> + * Kdump can exclude the HWPosion page to avoid touch the error page again,
>> + * the prerequisite is the PG_hwpoison page flag is set. However, for some
>> + * MCE fatal error cases, there are no opportunity to queue a task
>> + * for calling memory_failure(), as a result, the capture kernel panics.
>> + * This function marks the page as HWPoison before kernel panic() for MCE.
>> + */
>> +static void mce_set_page_hwpoison_now(unsigned long pfn)
>> +{
>> +	struct page *p;
>> +
>> +	p = pfn_to_online_page(pfn);
>> +	if (p)
>> +		SetPageHWPoison(p);
>> +}
> there's no need for that function - just put everything...
> 
>> +
>>  static void __print_mce(struct mce *m)
>>  {
>>  	pr_emerg(HW_ERR "CPU %d: Machine Check%s: %Lx Bank %d: %016Lx\n",
>> @@ -286,6 +302,8 @@ static noinstr void mce_panic(const char *msg, struct mce *final, char *exp)
>>  	if (!fake_panic) {
>>  		if (panic_timeout == 0)
>>  			panic_timeout = mca_cfg.panic_timeout;
>> +		if (final && (final->status & MCI_STATUS_ADDRV))
>> +			mce_set_page_hwpoison_now(final->addr >> PAGE_SHIFT);
> ... here, along with the comment.
> 

Good idea. I'll send V3 as you said.


Best Regards,
Zhiquan