From: Aili Yao <yaoaili@kingsoft.com>
To: <rjw@rjwysocki.net>, <lenb@kernel.org>, <tony.luck@intel.com>,
<bp@alien8.de>, <james.morse@arm.com>
Cc: <linux-acpi@vger.kernel.org>, <linux-edac@vger.kernel.org>,
<yangfeng1@kingsoft.com>, <CHENGUOMIN@kingsoft.com>
Subject: [PATCH v2] Dump cper error table in mce_panic
Date: Tue, 17 Nov 2020 17:58:04 +0800 [thread overview]
Message-ID: <20201117175804.39bbbdc3.yaoaili@kingsoft.com> (raw)
In-Reply-To: <20201104065057.40442-1-yaoaili126@163.com>
From 3b2602aa50f37321f9b05f9e377ac52f8a1db90a Mon Sep 17 00:00:00 2001
From: Aili Yao <yaoaili@kingsoft.com>
Date: Tue, 17 Nov 2020 17:41:54 +0800
Subject: [PATCH v2] Dump cper error table in mce_panic
For X86_MCE, When BIOS option WHEA memory log is enabled,if there is a
fatal ue error, BIOS will prepare one cper error table before raising MCE,
this cper table is meant to supply addtional error information and not to
race with mce handler to panic, but currently ghes_notify_nmi() from
unexpected NMI watchdog may race to panic with mce.
Usually possible unexpected cper process from NMI watchdog race panic
with MCE panic is not a problem, the panic process will coordinate with
each core. But When the CPER is not processed in the first kernel and
leave it to the second kernel, that is a problem, lead to a kdump fail.
Now in this patch, the mce_panic will race with unexpected NMI to dump
the cper error log and get it cleaned, this will prevent the cper table
leaked to the second kernel, which will prevent ghes_notify_nmi to
process and fix the kdump fail problem, and also guarrante the cper log is
collected which it's meant to.
Anyway,For x86_mce platform, the ghes module is better not to panic with
fatal memory UE as it's MCE handler's work.
Signed-off-by: Aili Yao <yaoaili@kingsoft.com>
---
arch/x86/kernel/cpu/mce/apei.c | 5 ++
arch/x86/kernel/cpu/mce/core.c | 2 +
arch/x86/kernel/cpu/mce/internal.h | 5 ++
drivers/acpi/apei/ghes.c | 78 ++++++++++++++++++++++++++++++
include/acpi/ghes.h | 6 +++
5 files changed, 96 insertions(+)
diff --git a/arch/x86/kernel/cpu/mce/apei.c b/arch/x86/kernel/cpu/mce/apei.c
index af8d37962586..d2dcae90613b 100644
--- a/arch/x86/kernel/cpu/mce/apei.c
+++ b/arch/x86/kernel/cpu/mce/apei.c
@@ -143,3 +143,8 @@ int apei_clear_mce(u64 record_id)
{
return erst_clear(record_id);
}
+
+int apei_check_cper(void)
+{
+ return ghes_in_mce_cper_entry_check();
+}
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index f43a78bde670..ce468bed352d 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -342,6 +342,8 @@ static void mce_panic(const char *msg, struct mce *final, char *exp)
if (!apei_err)
apei_err = apei_write_mce(final);
}
+ /* Print possible additional cper error info, get cper cleared */
+ apei_check_cper();
if (cpu_missing)
pr_emerg(HW_ERR "Some CPUs didn't answer in synchronization\n");
if (exp)
diff --git a/arch/x86/kernel/cpu/mce/internal.h b/arch/x86/kernel/cpu/mce/internal.h
index 6473070b5da4..ad68119fb15c 100644
--- a/arch/x86/kernel/cpu/mce/internal.h
+++ b/arch/x86/kernel/cpu/mce/internal.h
@@ -70,6 +70,7 @@ int apei_write_mce(struct mce *m);
ssize_t apei_read_mce(struct mce *m, u64 *record_id);
int apei_check_mce(void);
int apei_clear_mce(u64 record_id);
+int apei_check_cper(void);
#else
static inline int apei_write_mce(struct mce *m)
{
@@ -87,6 +88,10 @@ static inline int apei_clear_mce(u64 record_id)
{
return -EINVAL;
}
+static inline int apei_check_cper(void)
+{
+ return 0;
+}
#endif
/*
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 81bf71b10d44..80342e2f9760 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1084,6 +1084,84 @@ static void ghes_nmi_remove(struct ghes *ghes)
*/
synchronize_rcu();
}
+
+/*
+ * Only called by mce_panic, Return value will be ignored, just for debug
+ * purpose; when mce_panic is called, there may be meanwhile other hw error
+ * triggered through NMI, this function may lead that NMI unhandled,
+ * as we are in panic, collecting log will be sufficient.
+ */
+int ghes_in_mce_cper_entry_check(void)
+{
+ int ret = -ENOENT;
+ struct ghes *ghes;
+ struct list_head *rcu_list = &ghes_nmi;
+ enum fixed_addresses fixmap_idx = FIX_APEI_GHES_NMI;
+ struct acpi_hest_generic_status *estatus, tmp_header;
+ struct ghes_estatus_node *estatus_node;
+ u32 len, node_len;
+ u64 buf_paddr;
+
+ /* if NMI handler already in process, let NMI do its job */
+ if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
+ return 0;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ghes, rcu_list, list) {
+ int rc;
+
+ rc = __ghes_peek_estatus(ghes, &tmp_header, &buf_paddr, fixmap_idx);
+ if (rc) {
+ ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
+ ret = rc;
+ continue;
+ }
+
+ rc = __ghes_check_estatus(ghes, &tmp_header);
+ if (rc) {
+ ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
+ ret = rc;
+ continue;
+ }
+
+ len = cper_estatus_len(&tmp_header);
+ node_len = GHES_ESTATUS_NODE_LEN(len);
+ estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
+ if (!estatus_node) {
+ /* Going to panic, No need to keep the error. */
+ ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
+ ret = -ENOMEM;
+ continue;
+ }
+
+ estatus_node->ghes = ghes;
+ estatus_node->generic = ghes->generic;
+ estatus_node->task_work.func = NULL;
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+
+ if (__ghes_read_estatus(estatus, buf_paddr, fixmap_idx, len)) {
+ ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);
+ gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len);
+ ret = -ENOENT;
+ continue;
+ }
+
+ /*
+ * As we are going to panic, and preemt the possible NMI handing,
+ * dump all the info and get it cleared.
+ */
+ ghes_print_queued_estatus();
+ __ghes_print_estatus(KERN_EMERG, ghes->generic, estatus);
+ ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);
+
+ gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
+ node_len);
+ }
+
+ rcu_read_unlock();
+ atomic_dec(&ghes_in_nmi);
+ return ret;
+}
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
static inline void ghes_nmi_add(struct ghes *ghes) { }
static inline void ghes_nmi_remove(struct ghes *ghes) { }
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 517a5231cc1b..52a8638a0495 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -127,4 +127,10 @@ int ghes_notify_sea(void);
static inline int ghes_notify_sea(void) { return -ENOENT; }
#endif
+#if defined(CONFIG_ACPI_APEI_GHES) && defined(CONFIG_HAVE_ACPI_APEI_NMI)
+int ghes_in_mce_cper_entry_check(void);
+#else
+static inline int ghes_in_mce_cper_entry_check(void) { return 0; }
+#endif
+
#endif /* GHES_H */
--
2.25.1
next prev parent reply other threads:[~2020-11-17 9:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 6:50 [PATCH] Dump cper error table in mce_panic yaoaili126
2020-11-04 10:16 ` kernel test robot
2020-11-06 19:35 ` James Morse
2020-11-18 3:12 ` Aili Yao
2020-11-17 9:58 ` Aili Yao [this message]
2020-11-18 12:45 ` [PATCH v2] " Borislav Petkov
2020-11-19 5:40 ` Aili Yao
2020-11-19 17:45 ` Borislav Petkov
2020-11-20 3:40 ` Aili Yao
2020-11-20 9:22 ` Aili Yao
2020-11-20 10:24 ` Borislav Petkov
2021-01-28 12:01 ` Aili Yao
2021-01-28 17:22 ` Luck, Tony
2021-02-23 9:18 ` Aili Yao
2021-02-23 19:32 ` Luck, Tony
2021-02-24 9:56 ` Aili Yao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201117175804.39bbbdc3.yaoaili@kingsoft.com \
--to=yaoaili@kingsoft.com \
--cc=CHENGUOMIN@kingsoft.com \
--cc=bp@alien8.de \
--cc=james.morse@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
--cc=yangfeng1@kingsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox