All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yazen Ghannam <Yazen.Ghannam@amd.com>
To: linux-edac@vger.kernel.org
Cc: Borislav Petkov <bp@suse.de>, Tony Luck <tony.luck@intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2] x86/MCE/AMD: Always give PANIC severity for UC errors IN_KERNEL context
Date: Wed,  1 Nov 2017 13:59:06 -0500	[thread overview]
Message-ID: <1509562746-6313-1-git-send-email-Yazen.Ghannam@amd.com> (raw)

From: Yazen Ghannam <yazen.ghannam@amd.com>

The AMD severity grading function was introduced in v4.1 and has remained
logically unchanged with the exception of a separate SMCA severity grading
function for SMCA systems. The current logic can possibly give
MCE_AR_SEVERITY for uncorrectable errors in kernel context. The system may
then get stuck in a loop as memory_failure() will try to handle the bad
kernel memory and find it busy.

Return MCE_PANIC_SEVERITY for all UC errors IN_KERNEL context on AMD
systems.

After:

  b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")

was accepted in v4.6, this issue was masked because of the tail-end attempt
at kernel mode recovery in the #MC handler.

However, uncorrectable errors IN_KERNEL context should always be considered
unrecoverable and cause a panic.

Fixes: bf80bbd7dcf5 (x86/mce: Add an AMD severities-grading function)

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
[ This needs to be reworked to apply to v4.1 and v4.4 stable branches.]
Cc: <stable@vger.kernel.org> # 4.9.x
---
Link:
https://lkml.kernel.org/r/1505830031-9630-1-git-send-email-Yazen.Ghannam@amd.com

v1->v2:
* Update commit message.

 arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index 2773c8547f69..f5518706baa6 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -245,6 +245,9 @@ static int mce_severity_amd(struct mce *m, int tolerant, char **msg, bool is_exc
 
 	if (m->status & MCI_STATUS_UC) {
 
+		if (ctx == IN_KERNEL)
+			return MCE_PANIC_SEVERITY;
+
 		/*
 		 * On older systems where overflow_recov flag is not present, we
 		 * should simply panic if an error overflow occurs. If
@@ -255,10 +258,6 @@ static int mce_severity_amd(struct mce *m, int tolerant, char **msg, bool is_exc
 			if (mce_flags.smca)
 				return mce_severity_amd_smca(m, ctx);
 
-			/* software can try to contain */
-			if (!(m->mcgstatus & MCG_STATUS_RIPV) && (ctx == IN_KERNEL))
-				return MCE_PANIC_SEVERITY;
-
 			/* kill current process */
 			return MCE_AR_SEVERITY;
 		} else {
-- 
2.7.4

WARNING: multiple messages have this Message-ID (diff)
From: Yazen Ghannam <yazen.ghannam@amd.com>
To: linux-edac@vger.kernel.org
Cc: Borislav Petkov <bp@suse.de>, Tony Luck <tony.luck@intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [v2] x86/MCE/AMD: Always give PANIC severity for UC errors IN_KERNEL context
Date: Wed,  1 Nov 2017 13:59:06 -0500	[thread overview]
Message-ID: <1509562746-6313-1-git-send-email-Yazen.Ghannam@amd.com> (raw)

From: Yazen Ghannam <yazen.ghannam@amd.com>

The AMD severity grading function was introduced in v4.1 and has remained
logically unchanged with the exception of a separate SMCA severity grading
function for SMCA systems. The current logic can possibly give
MCE_AR_SEVERITY for uncorrectable errors in kernel context. The system may
then get stuck in a loop as memory_failure() will try to handle the bad
kernel memory and find it busy.

Return MCE_PANIC_SEVERITY for all UC errors IN_KERNEL context on AMD
systems.

After:

  b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")

was accepted in v4.6, this issue was masked because of the tail-end attempt
at kernel mode recovery in the #MC handler.

However, uncorrectable errors IN_KERNEL context should always be considered
unrecoverable and cause a panic.

Fixes: bf80bbd7dcf5 (x86/mce: Add an AMD severities-grading function)

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
[ This needs to be reworked to apply to v4.1 and v4.4 stable branches.]
Cc: <stable@vger.kernel.org> # 4.9.x
---
Link:
https://lkml.kernel.org/r/1505830031-9630-1-git-send-email-Yazen.Ghannam@amd.com

v1->v2:
* Update commit message.

 arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index 2773c8547f69..f5518706baa6 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -245,6 +245,9 @@ static int mce_severity_amd(struct mce *m, int tolerant, char **msg, bool is_exc
 
 	if (m->status & MCI_STATUS_UC) {
 
+		if (ctx == IN_KERNEL)
+			return MCE_PANIC_SEVERITY;
+
 		/*
 		 * On older systems where overflow_recov flag is not present, we
 		 * should simply panic if an error overflow occurs. If
@@ -255,10 +258,6 @@ static int mce_severity_amd(struct mce *m, int tolerant, char **msg, bool is_exc
 			if (mce_flags.smca)
 				return mce_severity_amd_smca(m, ctx);
 
-			/* software can try to contain */
-			if (!(m->mcgstatus & MCG_STATUS_RIPV) && (ctx == IN_KERNEL))
-				return MCE_PANIC_SEVERITY;
-
 			/* kill current process */
 			return MCE_AR_SEVERITY;
 		} else {

             reply	other threads:[~2017-11-01 18:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 18:59 Yazen Ghannam [this message]
2017-11-01 18:59 ` [v2] x86/MCE/AMD: Always give PANIC severity for UC errors IN_KERNEL context Yazen Ghannam
2017-11-03 12:02 ` [PATCH v2] " Borislav Petkov
2017-11-03 12:02   ` [v2] " Borislav Petkov

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=1509562746-6313-1-git-send-email-Yazen.Ghannam@amd.com \
    --to=yazen.ghannam@amd.com \
    --cc=bp@suse.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /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.