lkml.org 
[lkml]   [2020]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/6] x86/mce: Take action on UCNA/Deferred errors again
On Fri, Jan 03, 2020 at 04:07:17PM +0100, Jan H. Schönherr wrote:
> 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>

Tony, ACK?

Also, do you want it in stable@ so that it gets backported?

> 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);

I'm wondering if in the memory_failure error() case, we should hand it
down to the remaining notifiers.

Which also begs the question in light of this clumsy notifier counting:

How about we have the default notifier *unconditionally* print the MCE?
I.e., if the error has reached it, it would print it. If not and some
other notifier consumed it, it will get handled differently.

This way we won't need any special counting of notifiers and special
reg/unreg of notifiers etc.

IOW, the logic would be:

If something consumes the error, then it doesn't get printed. Notifier
does NOTIFY_STOP.

If nothing consumes it or something looks at it and decides that it
should still get printed, then the last catch-all notifier callback does
that.

Thoughts?

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

\
 
 \ /
  Last update: 2020-01-10 10:51    [W:0.106 / U:11.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site