mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Yazen Ghannam <Yazen.Ghannam@amd.com>
Cc: linux-edac@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/4] x86/mce: Add AMD SMCA support to SRAO notifier
Date: Wed, 22 Mar 2017 22:13:29 +0100	[thread overview]
Message-ID: <20170322211329.GE20697@nazgul.tnic> (raw)
In-Reply-To: <1490041614-90057-5-git-send-email-Yazen.Ghannam@amd.com>

On Mon, Mar 20, 2017 at 03:26:54PM -0500, Yazen Ghannam wrote:
> From: Yazen Ghannam <yazen.ghannam@amd.com>
> 
> Deferred errors on AMD systems may get an Action Optional severity with the
> goal of being handled by the SRAO notifier block. However, the process of
> determining if an address is usable is different between Intel and AMD. So
> define vendor-specific functions for this.
> 
> Also, check for the AO severity before determining if an address is usable
> to possibly save some cycles.
> 
> Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
> ---
> Link: http://lkml.kernel.org/r/1486760120-60944-3-git-send-email-Yazen.Ghannam@amd.com
> 
> v1->v2:
> - New in v2. Based on v1 patch 3.
> - Update SRAO notifier block to handle errors from SMCA systems.
> 
>  arch/x86/kernel/cpu/mcheck/mce.c | 52 ++++++++++++++++++++++++++++++----------
>  1 file changed, 40 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
> index 5e365a2..1a2669d 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -547,19 +547,49 @@ static void mce_report_event(struct pt_regs *regs)
>   * be somewhat complicated (e.g. segment offset would require an instruction
>   * parser). So only support physical addresses up to page granuality for now.
>   */
> -static int mce_usable_address(struct mce *m)
> +static int mce_usable_address_intel(struct mce *m, unsigned long *pfn)

So this function is basically saying whether the address is usable but
then it is also returning it if so.

And then it is using an I/O argument. Yuck.

So it sounds to me like this functionality needs redesign: something
like have a get_usable_address() function (the "mce_" prefix is not
really needed as it is static) which returns an invalid value when it
determines that it doesn't have a usable address and the address itself
if it succeeds.

>  {
> -	if (!(m->status & MCI_STATUS_MISCV) || !(m->status & MCI_STATUS_ADDRV))
> +	if (!(m->status & MCI_STATUS_MISCV))
>  		return 0;
> -
> -	/* Checks after this one are Intel-specific: */
> -	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> -		return 1;
> -
>  	if (MCI_MISC_ADDR_LSB(m->misc) > PAGE_SHIFT)
>  		return 0;
>  	if (MCI_MISC_ADDR_MODE(m->misc) != MCI_MISC_ADDR_PHYS)
>  		return 0;
> +
> +	*pfn = m->addr >> PAGE_SHIFT;
> +	return 1;
> +}
> +
> +/* Only support this on SMCA systems and errors logged from a UMC. */
> +static int mce_usable_address_amd(struct mce *m, unsigned long *pfn)
> +{
> +	u8 umc;
> +	u16 nid = cpu_to_node(m->extcpu);
> +	u64 addr;
> +
> +	if (!mce_flags.smca)
> +		return 0;

So on !SMCA systems there'll be no usable address ever! Even with
MCI_STATUS_ADDRV set.

Please *test* your stuff on all affected hardware before submitting.

> +
> +	umc = find_umc_channel(m);
> +
> +	if (umc < 0 || umc_normaddr_to_sysaddr(m->addr, nid, umc, &addr))
> +		return 0;
> +
> +	*pfn = addr >> PAGE_SHIFT;
> +	return 1;
> +}
> +
> +static int mce_usable_address(struct mce *m, unsigned long *pfn)
> +{
> +	if (!(m->status & MCI_STATUS_ADDRV))
> +		return 0;

What happened to the MCI_STATUS_MISCV bit check?

> +	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
> +		return mce_usable_address_intel(m, pfn);
> +
> +	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
> +		return mce_usable_address_amd(m, pfn);
> +
>  	return 1;

We definitely don't want to say that the address is usable on a third
vendor. It would be most likely a lie even if we never reach this code
on a third vendor.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

  parent reply	other threads:[~2017-03-22 21:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20 20:26 [PATCH v2 0/4] Call memory_failure() on Deferred errors Yazen Ghannam
2017-03-20 20:26 ` [PATCH v2 1/4] EDAC,mce_amd: Find node ID on SMCA systems using generic methods Yazen Ghannam
2017-03-20 20:26 ` [PATCH v2 2/4] x86/mce/AMD; EDAC,amd64: Move find_umc_channel() to AMD mcheck Yazen Ghannam
2017-03-22 21:16   ` Borislav Petkov
2017-03-22 21:41     ` Ghannam, Yazen
2017-03-20 20:26 ` [PATCH v2 3/4] x86/mce/AMD: Mark Deferred errors as Action Optional on SMCA systems Yazen Ghannam
2017-03-20 20:26 ` [PATCH v2 4/4] x86/mce: Add AMD SMCA support to SRAO notifier Yazen Ghannam
2017-03-21 21:47   ` Ghannam, Yazen
2017-03-22 21:13   ` Borislav Petkov [this message]
2017-03-22 21:40     ` Ghannam, Yazen

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=20170322211329.GE20697@nazgul.tnic \
    --to=bp@alien8.de \
    --cc=Yazen.Ghannam@amd.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®