This patchset includes grading of new types of machine errors on AMD's MCE
grading logic mce_severity_amd(), which helps the MCE handler determine
what actions to take. If the error is graded as a PANIC, the EDAC driver
will not decode; so we also include new error messages to describe the MCE
and help debugging critical errors.
Carlos Bilbao (2):
x86/mce: Extend AMD severity grading function with new types of errors
x86/mce: Add messages to describe panic machine errors on AMD's MCEs grading
arch/x86/include/asm/mce.h | 6 +
arch/x86/kernel/cpu/mce/severity.c | 203 ++++++++++++++++++++++++-----
2 files changed, 174 insertions(+), 35 deletions(-)
--
2.27.0
When a machine error is graded as PANIC by AMD grading logic, the MCE
handler calls mce_panic(). The notification chain does not come into effect
so the AMD EDAC driver does not decode the errors. In these cases, the
messages displayed to the user are more cryptic and miss information
that might be relevant, like the context in which the error took place.
Fix the above issue including messages on AMD's grading logic for machine
errors graded as PANIC.
Signed-off-by: Carlos Bilbao <[email protected]>
---
arch/x86/kernel/cpu/mce/severity.c | 33 ++++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/severity.c b/arch/x86/kernel/cpu/mce/severity.c
index 4a089e9dbbaf..11be63eaf7e5 100644
--- a/arch/x86/kernel/cpu/mce/severity.c
+++ b/arch/x86/kernel/cpu/mce/severity.c
@@ -330,10 +330,12 @@ static __always_inline int mce_severity_amd_smca(struct mce *m, enum context err
* Evaluate the severity of an overflow error for AMD systems, dependent on
* the recoverable features available.
*/
-static noinstr int mce_grade_overflow_amd(struct mce *m, enum context ctx)
+static noinstr int mce_grade_overflow_amd(struct mce *m, enum context ctx, char **msg)
{
int ret;
+ WARN_ON(!msg);
+
/*
* On older systems where overflow_recov flag is not present, we
* should simply panic if an error overflow occurs. If
@@ -343,6 +345,8 @@ static noinstr int mce_grade_overflow_amd(struct mce *m, enum context ctx)
if (mce_flags.overflow_recov) {
if (mce_flags.smca) {
ret = mce_severity_amd_smca(m, ctx);
+ if (ret == MCE_PANIC_SEVERITY)
+ *msg = "Uncorrected unrecoverable error";
} else {
/* kill current process */
ret = MCE_AR_SEVERITY;
@@ -351,8 +355,10 @@ static noinstr int mce_grade_overflow_amd(struct mce *m, enum context ctx)
}
/* at least one error was not logged */
- if (m->status & MCI_STATUS_OVER)
+ if (m->status & MCI_STATUS_OVER) {
+ *msg = "Overflow uncorrected";
return MCE_PANIC_SEVERITY;
+ }
/*
* For any other case, return MCE_UC_SEVERITY so that we log the
@@ -367,6 +373,7 @@ static noinstr int mce_grade_overflow_amd(struct mce *m, enum context ctx)
static noinstr int mce_severity_amd(struct mce *m, struct pt_regs *regs, char **msg, bool is_excp)
{
enum context ctx = error_context(m, regs);
+ char *severity_msg;
int ret;
/*
@@ -411,13 +418,16 @@ static noinstr int mce_severity_amd(struct mce *m, struct pt_regs *regs, char **
#ifdef CONFIG_MEMORY_FAILURE
ret = MCE_AR_SEVERITY;
#else
+ severity_msg = "Consumed poisoned data in kernel recoverable area";
ret = MCE_PANIC_SEVERITY;
#endif
break;
case IN_KERNEL:
+ severity_msg = "Attempt to consume poisoned data in kernel context";
ret = MCE_PANIC_SEVERITY;
break;
default:
+ severity_msg = "Attempt to consume poisoned data in unknown context";
ret = MCE_PANIC_SEVERITY;
}
@@ -426,6 +436,7 @@ static noinstr int mce_severity_amd(struct mce *m, struct pt_regs *regs, char **
/* Processor Context Corrupt, no need to fumble too much, die! */
if (m->status & MCI_STATUS_PCC) {
+ severity_msg = "Processor Context Corrupt";
ret = MCE_PANIC_SEVERITY;
goto amd_severity;
}
@@ -441,9 +452,11 @@ static noinstr int mce_severity_amd(struct mce *m, struct pt_regs *regs, char **
ret = MCE_AR_SEVERITY;
break;
case IN_KERNEL:
+ severity_msg = "Data load error in unrecoverable kernel context";
ret = MCE_PANIC_SEVERITY;
break;
default:
+ severity_msg = "Data load error in unknown context";
ret = MCE_PANIC_SEVERITY;
}
@@ -464,13 +477,16 @@ static noinstr int mce_severity_amd(struct mce *m, struct pt_regs *regs, char **
#ifdef CONFIG_MEMORY_FAILURE
ret = MCE_AR_SEVERITY;
#else
+ severity_msg = "Instruction fetch error in kernel recoverable area";
ret = MCE_PANIC_SEVERITY;
#endif
break;
case IN_KERNEL:
+ severity_msg = "Instruction fetch error in kernel context";
ret = MCE_PANIC_SEVERITY;
break;
default:
+ severity_msg = "Instruction fetch error in unknown context";
ret = MCE_PANIC_SEVERITY;
}
@@ -478,15 +494,24 @@ static noinstr int mce_severity_amd(struct mce *m, struct pt_regs *regs, char **
}
if (m->status & MCI_STATUS_OVER) {
- ret = mce_grade_overflow_amd(m, ctx);
+ ret = mce_grade_overflow_amd(m, ctx, &severity_msg);
goto amd_severity;
}
- if (ctx == IN_KERNEL)
+ if (ctx == IN_KERNEL) {
+ severity_msg = "Uncorrectable error in kernel context";
ret = MCE_PANIC_SEVERITY;
+ }
amd_severity:
+ /*
+ * It only makes sense to provide a message on panic scenarios,
+ * as otherwise EDAC will be notified and conduct the decoding.
+ */
+ if (msg && ret == MCE_PANIC_SEVERITY)
+ *msg = severity_msg;
+
return ret;
}
--
2.27.0
On Mon, Mar 28, 2022 at 08:41:30AM -0500, Carlos Bilbao wrote:
> This patchset includes grading of new types of machine errors on AMD's MCE
> grading logic mce_severity_amd(), which helps the MCE handler determine
> what actions to take. If the error is graded as a PANIC, the EDAC driver
> will not decode; so we also include new error messages to describe the MCE
> and help debugging critical errors.
>
> Carlos Bilbao (2):
> x86/mce: Extend AMD severity grading function with new types of errors
> x86/mce: Add messages to describe panic machine errors on AMD's MCEs grading
>
> arch/x86/include/asm/mce.h | 6 +
> arch/x86/kernel/cpu/mce/severity.c | 203 ++++++++++++++++++++++++-----
> 2 files changed, 174 insertions(+), 35 deletions(-)
How is this submission different from
https://lore.kernel.org/r/[email protected]
?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 3/28/2022 8:55 AM, Borislav Petkov wrote:
> On Mon, Mar 28, 2022 at 08:41:30AM -0500, Carlos Bilbao wrote:
>> This patchset includes grading of new types of machine errors on AMD's MCE
>> grading logic mce_severity_amd(), which helps the MCE handler determine
>> what actions to take. If the error is graded as a PANIC, the EDAC driver
>> will not decode; so we also include new error messages to describe the MCE
>> and help debugging critical errors.
>>
>> Carlos Bilbao (2):
>> x86/mce: Extend AMD severity grading function with new types of errors
>> x86/mce: Add messages to describe panic machine errors on AMD's MCEs grading
>>
>> arch/x86/include/asm/mce.h | 6 +
>> arch/x86/kernel/cpu/mce/severity.c | 203 ++++++++++++++++++++++++-----
>> 2 files changed, 174 insertions(+), 35 deletions(-)
>
> How is this submission different from
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2F20220311165114.482074-1-carlos.bilbao%40amd.com&data=04%7C01%7Ccarlos.bilbao%40amd.com%7C7355a7de9b224557d6cf08da10c29e56%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637840725342715892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=A809HxzZHYiZQ6Arlje0o9KAFt4c77I2Q4vOfCl9%2Fis%3D&reserved=0
>
> ?
Just fixed a typo in the first patch -I should have included a change log.
Thanks,
Carlos
>
On Mon, Mar 28, 2022 at 08:57:04AM -0500, Carlos Bilbao wrote:
> Just fixed a typo in the first patch -I should have included a change log.
Well, we have the merge window open currently:
Merge window
^^^^^^^^^^^^
Please do not expect large patch series to be handled during the merge
window or even during the week before. Such patches should be submitted in
mergeable state *at* *least* a week before the merge window opens.
Exceptions are made for bug fixes and *sometimes* for small standalone
drivers for new hardware or minimally invasive patches for hardware
enablement.
During the merge window, the maintainers instead focus on following the
upstream changes, fixing merge window fallout, collecting bug fixes, and
allowing themselves a breath. Please respect that.
The release candidate -rc1 is the starting point for new patches to be
applied which are targeted for the next merge window.
---
and since you're new to this, I'd suggest you take the
time to read Documentation/process/ and especially
Documentation/process/submitting-patches.rst while waiting.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 3/28/2022 9:04 AM, Borislav Petkov wrote:
> On Mon, Mar 28, 2022 at 08:57:04AM -0500, Carlos Bilbao wrote:
>> Just fixed a typo in the first patch -I should have included a change log.
>
> Well, we have the merge window open currently:
>
> Merge window
> ^^^^^^^^^^^^
>
> Please do not expect large patch series to be handled during the merge
> window or even during the week before. Such patches should be submitted in
> mergeable state *at* *least* a week before the merge window opens.
> Exceptions are made for bug fixes and *sometimes* for small standalone
> drivers for new hardware or minimally invasive patches for hardware
> enablement.
>
> During the merge window, the maintainers instead focus on following the
> upstream changes, fixing merge window fallout, collecting bug fixes, and
> allowing themselves a breath. Please respect that.
>
> The release candidate -rc1 is the starting point for new patches to be
> applied which are targeted for the next merge window.
>
> ---
>
> and since you're new to this, I'd suggest you take the
> time to read Documentation/process/ and especially
> Documentation/process/submitting-patches.rst while waiting.
>
> Thx.
>
Thanks Borislav -would you like me to resend this once -rc1 opens?
Best,
Carlos
On Mon, Mar 28, 2022 at 09:09:04AM -0500, Carlos Bilbao wrote:
> Thanks Borislav -would you like me to resend this once -rc1 opens?
No need - I have it already. Btw, those documents also explain when
to resend: when the patches need to be changed or when they've been
forgotten. Most people usually send a "ping email" as a reply to the
thread to remind the maintainer to handle them, in that latter case.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette