All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan H. Schönherr" <jschoenh@amazon.de>
To: Borislav Petkov <bp@alien8.de>
Cc: "Jan H. Schönherr" <jschoenh@amazon.de>,
	"Yazen Ghannam" <yazen.ghannam@amd.com>,
	linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
	"Tony Luck" <tony.luck@intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org
Subject: [PATCH v2 1/6] x86/mce: Take action on UCNA/Deferred errors again
Date: Fri,  3 Jan 2020 16:07:17 +0100	[thread overview]
Message-ID: <20200103150722.20313-2-jschoenh@amazon.de> (raw)
In-Reply-To: <20200103150722.20313-1-jschoenh@amazon.de>

Commit fa92c5869426 ("x86, mce: Support memory error recovery for both
UCNA and Deferred error in machine_check_poll") added handling of UCNA
and Deferred errors by adding them to the ring for SRAO errors.

Later, commit fd4cf79fcc4b ("x86/mce: Remove the MCE ring for Action
Optional errors") switched storage from the SRAO ring to the unified
pool that is still in use today. In order to only act on the intended
errors, a filter for MCE_AO_SEVERITY is used -- effectively removing
handling of UCNA/Deferred errors again.

Extend the severity filter to include UCNA/Deferred errors again.
Also, generalize the naming of the notifier from SRAO to UC to capture
the extended scope.

Note, that this change may cause a message like the following to appear,
as the same address may be reported as SRAO and as UCNA:

 Memory failure: 0x5fe3284: already hardware poisoned

Technically, this is a return to previous behavior.

Fixes: fd4cf79fcc4b ("x86/mce: Remove the MCE ring for Action Optional errors")
Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
---
Changes v1->v2:
- rename notifier from SRAO to UC (as requested by Tony)
- extend commit message (per remark from Tony)
- don't mention Linux versions (per remark from Boris)

There was some discussion on v1, whether the SRAO/UC notifier does
the right thing or not. While it seems to be correct as is for Intel
(per Tony), there were some concerns for AMD (per Yazen). Hence, there
is a new patch 5 in this series, which disables the notifier on AMD.
---
 arch/x86/include/asm/mce.h     |  2 +-
 arch/x86/kernel/cpu/mce/core.c | 31 ++++++++++++++++---------------
 2 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index dc2d4b206ab7..c8ff6f6750ef 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -144,7 +144,7 @@ struct mce_log_buffer {
 
 enum mce_notifier_prios {
 	MCE_PRIO_FIRST		= INT_MAX,
-	MCE_PRIO_SRAO		= INT_MAX - 1,
+	MCE_PRIO_UC		= INT_MAX - 1,
 	MCE_PRIO_EXTLOG		= INT_MAX - 2,
 	MCE_PRIO_NFIT		= INT_MAX - 3,
 	MCE_PRIO_EDAC		= INT_MAX - 4,
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 8994fe7751a4..16134ce587fd 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -156,10 +156,8 @@ void mce_log(struct mce *m)
 }
 EXPORT_SYMBOL_GPL(mce_log);
 
-static struct notifier_block mce_srao_nb;
-
 /*
- * We run the default notifier if we have only the SRAO, the first and the
+ * We run the default notifier if we have only the UC, the first and the
  * default notifier registered. I.e., the mandatory NUM_DEFAULT_NOTIFIERS
  * notifiers registered on the chain.
  */
@@ -580,26 +578,29 @@ static struct notifier_block first_nb = {
 	.priority	= MCE_PRIO_FIRST,
 };
 
-static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
-				void *data)
+static int uc_decode_notifier(struct notifier_block *nb, unsigned long val,
+			      void *data)
 {
 	struct mce *mce = (struct mce *)data;
 	unsigned long pfn;
 
-	if (!mce)
+	if (!mce || !mce_usable_address(mce))
 		return NOTIFY_DONE;
 
-	if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
-		pfn = mce->addr >> PAGE_SHIFT;
-		if (!memory_failure(pfn, 0))
-			set_mce_nospec(pfn);
-	}
+	if (mce->severity != MCE_AO_SEVERITY &&
+	    mce->severity != MCE_DEFERRED_SEVERITY)
+		return NOTIFY_DONE;
+
+	pfn = mce->addr >> PAGE_SHIFT;
+	if (!memory_failure(pfn, 0))
+		set_mce_nospec(pfn);
 
 	return NOTIFY_OK;
 }
-static struct notifier_block mce_srao_nb = {
-	.notifier_call	= srao_decode_notifier,
-	.priority	= MCE_PRIO_SRAO,
+
+static struct notifier_block mce_uc_nb = {
+	.notifier_call	= uc_decode_notifier,
+	.priority	= MCE_PRIO_UC,
 };
 
 static int mce_default_notifier(struct notifier_block *nb, unsigned long val,
@@ -1970,7 +1971,7 @@ int __init mcheck_init(void)
 {
 	mcheck_intel_therm_init();
 	mce_register_decode_chain(&first_nb);
-	mce_register_decode_chain(&mce_srao_nb);
+	mce_register_decode_chain(&mce_uc_nb);
 	mce_register_decode_chain(&mce_default_nb);
 	mcheck_vendor_init_severity();
 
-- 
2.22.0.3.gb49bb57c8208.dirty


  reply	other threads:[~2020-01-03 15:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-03 15:07 [PATCH v2 0/6] x86/mce: Various fixes and cleanups for MCE handling Jan H. Schönherr
2020-01-03 15:07 ` Jan H. Schönherr [this message]
2020-01-10  9:50   ` [PATCH v2 1/6] x86/mce: Take action on UCNA/Deferred errors again Borislav Petkov
2020-01-10 18:45     ` Luck, Tony
2020-01-11 13:06       ` Borislav Petkov
2020-01-11 13:17       ` Borislav Petkov
2020-01-03 15:07 ` [PATCH v2 2/6] x86/mce: Make mce=nobootlog work again Jan H. Schönherr
2020-01-03 15:07 ` [PATCH v2 3/6] x86/mce: Fix use of uninitialized MCE message string Jan H. Schönherr
2020-01-03 15:07 ` [PATCH v2 4/6] x86/mce: Allow a variable number of internal MCE decode notifiers Jan H. Schönherr
2020-01-03 15:07 ` [PATCH v2 5/6] x86/mce: Do not take action on SRAO/Deferred errors on AMD for now Jan H. Schönherr
2020-01-03 15:07 ` [PATCH v2 6/6] x86/mce: Dynamically register default MCE handler Jan H. Schönherr
2020-01-03 19:46   ` Luck, Tony
2020-01-03 21:42   ` Luck, Tony
2020-01-03 22:03   ` Borislav Petkov
2020-01-08  4:24     ` Ghannam, Yazen
2020-01-08 10:03       ` Borislav Petkov
2020-01-09 20:39         ` Ghannam, Yazen
2020-01-09 21:54           ` Luck, Tony
2020-01-09 22:30             ` Jan H. Schönherr
2020-01-04 11:49   ` kbuild test robot
2020-01-04 11:49     ` kbuild test robot

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=20200103150722.20313-2-jschoenh@amazon.de \
    --to=jschoenh@amazon.de \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.