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

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

  reply	other threads:[~2020-01-10  9:50 UTC|newest]

Thread overview: 20+ 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 ` [PATCH v2 1/6] x86/mce: Take action on UCNA/Deferred errors again Jan H. Schönherr
2020-01-10  9:50   ` Borislav Petkov [this message]
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

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=20200110095004.GD19453@zn.tnic \
    --to=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jschoenh@amazon.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).