Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Message-ID: <233e17ac-0ae5-4392-a5e4-ab811a155805@intel.com>
Date:   Sat, 14 Oct 2023 17:34:12 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/mce: Set PG_hwpoison page flag to avoid the
 capture kernel panic
Content-Language: en-US
To:     "Luck, Tony" <tony.luck@intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "patches@lists.linux.dev" <patches@lists.linux.dev>,
        "bp@alien8.de" <bp@alien8.de>,
        "mingo@kernel.org" <mingo@kernel.org>,
        "naoya.horiguchi@nec.com" <naoya.horiguchi@nec.com>
CC:     <zhiquan1.li@intel.com>
References: <20231014051754.3759099-1-zhiquan1.li@intel.com>
 <SJ1PR11MB6083A23BB89F4EE0F44B2794FCD1A@SJ1PR11MB6083.namprd11.prod.outlook.com>
From:   Zhiquan Li <zhiquan1.li@intel.com>
In-Reply-To: <SJ1PR11MB6083A23BB89F4EE0F44B2794FCD1A@SJ1PR11MB6083.namprd11.prod.outlook.com>
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?ejNKTE5HdjdMOW0vN2RuV2N3dnBxZnRXVmVTYjQySVMzUUR0eXhBRWhRNGd2?=
 =?utf-8?B?bkhNYkFXTklXM0Z3YWhDbkh5T0dtNVZrUmxyK3Q5M2JuT2dqNzBpRFIyT0ta?=
 =?utf-8?B?ekwrK0ZHcm10ejJrT2JGNDNET2pDNnhTbWNjNmhWUGwrcExlWDBYaXo2Y1lz?=
 =?utf-8?B?T0JlRENUQzBaS0lVQjUwSUJWVEFkcVBGYnl5MHZLWEVsVSs0aFVreGNFWGNL?=
 =?utf-8?B?SmU1RFhFWWVUcURvWGZSTEVxWVRKRk4xZWlHQnRzZGlETGJ4SlJ5ajhMSVFI?=
 =?utf-8?B?M3huYklRSUc2WlU1NWt2VGg5bHQ5NjM4bjJxcytWK3pLRXJqTXZzMHV1OGhY?=
 =?utf-8?B?a09kQmFocjdKa0dhNHBlVUIwRlh2RGd4TUtMeHgxOGNicDBCMXVPdHgzamtT?=
 =?utf-8?B?UHVEUm8vdVhnalplM0Y0NFcwczZWQzc0bkdrdWdkbm95SVhFU2xadlo4Uy9k?=
 =?utf-8?B?cmFNcVBCaXVlaUhHaG1wRmRjdk01SmJWYThkTm1JQXpQZzlvUXNSaVNuK2Zz?=
 =?utf-8?B?UWhKSlREUUNzL01rVXJyRXd4dGJUVUZrUnp1bEF0VFJRZWxBcXFRWDEwREs0?=
 =?utf-8?B?dmNhK3ZIbC94WE1wRlFNK3dmZGhpWnVsZzZLS2hqbVEyUkYwb0I3eUIrTGZB?=
 =?utf-8?B?VGJNTHM3Y21BdFFSM2ZRT0VremdUUk9DajNob0kzVXFQajVDbC83ZTlvK1Ro?=
 =?utf-8?B?UVBEUis0QkpGYi9lODc5VFQvZWxtR3pHMUZsem4rdTdiRjNSMnRwN2gvZXhl?=
 =?utf-8?B?UWs4ODRpSmNtL0pxRWYra1Z0US9oMkNUWG83cVpBTGpNNUd3SmJtZko3TWtN?=
 =?utf-8?B?Y1JzTmE4L0U0SGlaZlhYSDZxOEtuaVZmYlFrZGRjTUZHMzNGdFdHRnJVS1Vj?=
 =?utf-8?B?RitFMTJFeVphLzhmd3NVSGZNaTJHWWhSN1J4SDBpQTlVR1FxRi9udzNRY1Nw?=
 =?utf-8?B?eC9jQzZDem1mcDBUZXovbnFYWFBleDVTMStPNk9ka3hybUVhR3hLdWdNV0lU?=
 =?utf-8?B?RGpFczdjK3NWbnpnODBUZytNRHdMelNlLzhRNGxGL2dmQi9vbGR2SkV2Z1ZW?=
 =?utf-8?B?OWdMby9RcUd6bGtWV2d5NnpQbWh1NmtzL0QvVk5KZk5kMjFiZkZLNUx0R2sy?=
 =?utf-8?B?OHZDVU9wK0hHVzVwdWNISitBVEV1aTZodHBRUnVWdnkrQ1k1bm0yTVlZeW9m?=
 =?utf-8?B?K3B0NVlnaWZwa3BIblU2UVluZVo3a2x1SWdZbVBucVFCVUxXTE9JTkhTdVc0?=
 =?utf-8?B?WGVic2NEZXlnR21OWENVWHFLYTRQZHE3QUlsNVRXdXJzTTJoL05NVjhlbytT?=
 =?utf-8?B?Q0w4THZ0OFdyYzZoQXNSV3FCeW4zUXF6VFZyOG9RVTRnd2RRcHFFMDdBazVC?=
 =?utf-8?B?WEFUYjZNUkU2cGNhOVBJdVM2em14T1V4OUFLeitSbDBiWGtlYW5MczBHOHRU?=
 =?utf-8?B?MmtVUzg0SVVXdUFoblBEOTd5QUxVZXp6elJZU2p5d1V5UnpQMzJSbXhQcGFO?=
 =?utf-8?B?TDJvRGRZWWoyU090aTNrWDl4bFZodVZaMktDTTgyNU1EUEN5eG1rRXZRKzhi?=
 =?utf-8?B?aUI1bldZYi9oQ1E0ZnVRWEhDOWM1RTJvNnkvSzhnamQ2KzhGbzZSMTQ0Zmtr?=
 =?utf-8?B?ZkZGdmhSeFV5cnYxVGJMWHNxakJKT1JFSmRaa2xjaExsSEhTMG9KVmlENzRm?=
 =?utf-8?B?K2gxQ29tNGowa3pKakxEUHc3aWcyVFZwNUVuTnBLaEppQVovNnZ3TGdReWl4?=
 =?utf-8?B?RnNsTHBTVWZaRE5DUzcybnQrUDBhVGNyZUp5aTUrc0Vialp5VnZjS2NtcGhR?=
 =?utf-8?B?VDdBVUliUHZldEttL1EyaHFBZGo4VVN3SjlteE4ydmx1eVFKZWlzUnhEUXFw?=
 =?utf-8?B?OTBscTVqTjNWQjF0QmlNSHpzZlBjRytucHUzVGxIL0VPU2F2MzFXOE1CQjNZ?=
 =?utf-8?B?aGVQYXU4eFBGY2J6cjErM3JDVkRwdnMzdjRlN1lSMVl1ckZmT29paU8rd2FS?=
 =?utf-8?B?cHd3U1lPcXQrK1ZXUFdSS2l1SUl5Mk9kenhtTGVRQ3dIZ2Y3aFdrRjdsK1pn?=
 =?utf-8?B?TThKK3o5UTBrMkdkdVNBZXc1K1d4Y3hrS01lcWp2aCtlVzM0bm1HQnNjUk5u?=
 =?utf-8?Q?o4wTlwC/4DE8xdUHQvypz5CoU?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e593b7ae-bf85-45b6-4286-08dbcc9618f9
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3728.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2023 09:15:24.0225
 (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: u1lydsvbq2l8VhBet99FtYt5QJa5JdyxktI0N73SUF6IfN5N0wymCv42wETUQiiCXPiTuFXEmKJIk7zEZOm2qQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5227
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
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 (snail.vger.email [0.0.0.0]); Sat, 14 Oct 2023 02:15:41 -0700 (PDT)

On 2023/10/14 13:12, Luck, Tony wrote:
>> 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>
>> Signed-off-by: Ingo Molnar <mingo@kernel.org>
>> Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Link: https://lore.kernel.org/all/20230719211625.298785-1-tony.luck@intel.com/#t
> 
> This still has problems.  You should have removed my Signed-off-by. You should NOT
> have added Ingo's Signed-off-by (the only time to add someone else's Signed-off-by
> is when paired with a Co-developed-by).
> 

Oh, this is V3, not RESEND, I should reset the SoB chain.
Thanks for your reminder, Tony.

If my understanding is correct, the version below fixes the tag list.

Best Regards,
Zhiquan

========>
From: Zhiquan Li <zhiquan1.li@intel.com>
Date: Sat, 14 Oct 2023 13:03:17 -0600
Subject: [PATCH v3] x86/mce: Set PG_hwpoison page flag to avoid the capture kernel panic

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.  For some MCE fatal error cases, the kernel might call
mce_panic() to terminate the production kernel directly, thus there is
no opportunity to queue a task for calling memory_failure() which will
try to make the kernel survive via memory failure handling.

Unfortunately, the capture kernel will panic for the same reason if it
touches the error memory again.  The consequence is that only an
incomplete vmcore is left for sustaining engineers, it's a big headache
for them to make clear what happened in the past.

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.

Likewise, the dump program can exclude the poisoned page to avoid
touching the error page again, the prerequisite is the PG_hwpoison page
flag is set correctly by kernel.  The de facto dump program
(makedumpfile) already supports this function in a decade ago.  To set
the PG_hwpoison flag in the production kernel just before it panics is
the only missing step to make everything work.

And it would not introduce additional overhead in capture kernel or
conflict with other hwpoision-related code in production kernel.  It
leverages the already existing mechanisms to fix the issue as much as
possible, so the code changes are lightweight.

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>
Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Borislav Petkov <bp@alien8.de>

---

V2: https://lore.kernel.org/all/20230914030539.1622477-1-zhiquan1.li@intel.com/

Changes since V2:
- Rebased to v6.6-rc5.
- Explained full scenario in commit message per Boris's suggestion.
- Included Ingo's fixes.
  Link: https://lore.kernel.org/all/ZRsUpM%2FXtPAE50Rm@gmail.com/

V1: https://lore.kernel.org/all/20230127015030.30074-1-tony.luck@intel.com/

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.
- Added the tag from Naoya.
  Link: https://lore.kernel.org/all/20230327083739.GA956278@hori.linux.bs1.fc.nec.co.jp/
---
 arch/x86/kernel/cpu/mce/core.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 6f35f724cc14..905e80c776b8 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -233,6 +233,7 @@ static noinstr void mce_panic(const char *msg, struct mce *final, char *exp)
 	struct llist_node *pending;
 	struct mce_evt_llist *l;
 	int apei_err = 0;
+	struct page *p;
 
 	/*
 	 * Allow instrumentation around external facilities usage. Not that it
@@ -286,6 +287,17 @@ 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;
+		/*
+		 * Kdump can exclude the HWPoison page to avoid touching the error
+		 * page again, the prerequisite is that the PG_hwpoison page flag is
+		 * set.  However, for some MCE fatal error cases, there is no
+		 * opportunity to queue a task for calling memory_failure(), and as a
+		 * result, the capture kernel panics.  So mark the page as HWPoison
+		 * before kernel panic() for MCE.
+		 */
+		p = pfn_to_online_page(final->addr >> PAGE_SHIFT);
+		if (final && (final->status & MCI_STATUS_ADDRV) && p)
+			SetPageHWPoison(p);
 		panic(msg);
 	} else
 		pr_emerg(HW_ERR "Fake kernel panic: %s\n", msg);
-- 
2.25.1