Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp1364229rdg; Fri, 13 Oct 2023 21:59:41 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGsT2nOZiXNA950wu2cUrbL8kxlSGFgxaZ/Cr7sQrSTLPNZGYPJUvHSjTNtakliuSqZFgLJ X-Received: by 2002:a05:6a21:a586:b0:16b:bbca:4a5d with SMTP id gd6-20020a056a21a58600b0016bbbca4a5dmr22258766pzc.62.1697259581288; Fri, 13 Oct 2023 21:59:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697259581; cv=none; d=google.com; s=arc-20160816; b=Kfkz03WKI9rt6J4JCUHAr4oHOCRAHxcgvvVdrabix5ICLF/IaGHL5jrjbkDzqBJIWk ZEpFbJflUnwwH17tckjvKFb0Uzz52eAh9bgV3BOofzo+DUs2GxEPL2FXuIdf0TO8n4Z4 6prr4Db+sdGgOyJ9awKJ57XFJWqH6c0nlqY+sAs7oig1YeouW9Bi0K4Zj6v7YPmphQco o6w+SVLN/4Khk8WQJnOXObNQ9PHJGNSqJmQnNsBFbVfXfyjSXHB1BvSktydhj6W7nr9I 8b2O/dSbPVOx28h2u4JDCP6g2iUDlGiseOxPEQByLNd4RHzSBqYEP/uottR92x1KUWoJ VgFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=YT6Bi+9ei4vp84fmo7iN45Hia4SyDrrnmD+X9JhONgM=; fh=Th+hEBE7R9KyrpApgvpywP1XpX3e8rW1gDPfcl4UJqI=; b=rvM7Ha8iDSssuV1qeRMVw1eD8BFBFafcWmDdHzL69x3ju+Pbe9VhZYnKc4dSrGT2dh hwRLbIERddjJfZ7Qm+4qLKwj7jRxNibFAjB+OO4TUFDvWylgAyX6gqpG7y87sg+aOM8G VVk046tBCMK8Kpg/kGA3bVdFWcrckA4teDAmlwUnTmh4uwXDuFXbrF4IV1LKXsltg628 VbBj21JtYMDOlTwpe4oMSxw1vsFQ9Aodrdpdw+7CA3B5FkVVnYVMe7Yk3Kr1pN1fWXVw fXk5n5c/9Ntb9+Bdast/o0I5bUvxh0prCIU5DMcvg7sr2lS4V4HBPhq7PkZz5khLT3dY AX9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="IdG/eDly"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id bi8-20020a170902bf0800b001c6182d7d43si5739179plb.21.2023.10.13.21.59.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 21:59:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="IdG/eDly"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id A33AD8369F58; Fri, 13 Oct 2023 21:59:38 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232793AbjJNE7W (ORCPT + 99 others); Sat, 14 Oct 2023 00:59:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbjJNE7V (ORCPT ); Sat, 14 Oct 2023 00:59:21 -0400 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 966BBC0; Fri, 13 Oct 2023 21:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697259560; x=1728795560; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=/mdnpue4Nciffio8GLONGA7omAPMeo1KzhFrOJHbT50=; b=IdG/eDlyXiJdn5TnWybYDn5od4OulhefWGyHHV1KPCFQTDVni5u4HI5K tZEXaqSS9SDkRTrQQOx6ARjhgOZzYShkt+N3r87D67+TCH0yyxDaLVbeD oVlmk7bHnxtpvIwgAow6FOQPyR9+piBkF3HC/pmHEgxtG2ZjDdgzB3pDf AQl3VLR6cI9lOK9oXcetx1qUkVlHih5TI1sqY63ec9/++OYylTLLynYsI wvqXawSWThEQbilOpaVhNIF/g7xTzuFvoKP7fGv7h45UbTRZD31Ix9wG7 xXL8zOOp0QyZZg+blG1nSK16d86MYf630I6pfMW45WNwksIQO6yyz9EbC w==; X-IronPort-AV: E=McAfee;i="6600,9927,10862"; a="3912769" X-IronPort-AV: E=Sophos;i="6.03,224,1694761200"; d="scan'208";a="3912769" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2023 21:59:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10862"; a="871363248" X-IronPort-AV: E=Sophos;i="6.03,224,1694761200"; d="scan'208";a="871363248" Received: from zhiquan-linux-dev.bj.intel.com ([10.238.156.102]) by fmsmga002.fm.intel.com with ESMTP; 13 Oct 2023 21:58:57 -0700 From: Zhiquan Li To: x86@kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev, bp@alien8.de, mingo@kernel.org, tony.luck@intel.com, naoya.horiguchi@nec.com Cc: zhiquan1.li@intel.com, Youquan Song Subject: [PATCH v3] x86/mce: Set PG_hwpoison page flag to avoid the capture kernel panic Date: Sat, 14 Oct 2023 13:17:54 +0800 Message-Id: <20231014051754.3759099-1-zhiquan1.li@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 13 Oct 2023 21:59:38 -0700 (PDT) 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. [ Tony: Changed TestSetPageHWPoison() to SetPageHWPoison() ] [ mingo: Fixed the comments & changelog ] Co-developed-by: Youquan Song Signed-off-by: Youquan Song Signed-off-by: Zhiquan Li Signed-off-by: Tony Luck Signed-off-by: Ingo Molnar Reviewed-by: Naoya Horiguchi Cc: Borislav Petkov Link: https://lore.kernel.org/all/20230719211625.298785-1-tony.luck@intel.com/#t --- 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