linux-kernel - Re: [PATCH v3 2/2] x86, mce: support memory error recovery for both UCNA and Deferred error in machine_check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 10 Nov 2014 20:06:17 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Chen Yucong <slaoub@...il.com>
Cc:	tony.luck@...el.com, ak@...ux.intel.com,
	aravind.gopalakrishnan@....com, linux-edac@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] x86, mce: support memory error recovery for both
 UCNA and Deferred error in machine_check_poll

On Sat, Nov 08, 2014 at 09:40:21AM +0800, Chen Yucong wrote:
> Uncorrected no action required (UCNA) - is a uncorrected recoverable
> machine check error that is not signaled via a machine check exception
> and, instead, is reported to system software as a corrected machine
> check error. UCNA errors indicate that some data in the system is
> corrupted, but the data has not been consumed and the processor state
> is valid and you may continue execution on this processor. UCNA errors
> require no action from system software to continue execution. Note that
> UCNA errors are supported by the processor only when IA32_MCG_CAP[24]
> (MCG_SER_P) is set.
>                                                -- Intel SDM Volume 3B
> 
> Deferred errors are errors that cannot be corrected by hardware, but
> do not cause an immediate interruption in program flow, loss of data
> integrity, or corruption of processor state. These errors indicate
> that data has been corrupted but not consumed. Hardware writes information
> to the status and address registers in the corresponding bank that
> identifies the source of the error if deferred errors are enabled for
> logging. Deferred errors are not reported via machine check exceptions;
> they can be seen by polling the MCi_STATUS registers.
>                                                 -- AMD64 APM Volume 2
> 
> Above two items, both UCNA and Deferred errors belong to detected
> errors, but they can't be corrected by hardware, and this is very
> similar to Software Recoverable Action Optional (SRAO) errors.
> Therefore, we can take some actions that have been used for handling
> SRAO errors to handle UCNA and Deferred errors.
> 
> Signed-off-by: Chen Yucong <slaoub@...il.com>
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c |   50 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
> index 453e9bf..4b6e4cdf 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -575,6 +575,41 @@ static void mce_read_aux(struct mce *m, int i)
>  	}
>  }
>  
> +static bool memory_error(struct mce *m)
> +{
> +	struct cpuinfo_x86 *c = &boot_cpu_data;
> +
> +	if (c->x86_vendor == X86_VENDOR_AMD) {
> +		/*
> +		 * AMD BKDGs - Machine Check Error Codes
> +		 *
> +		 * Bit 8 of ErrCode[15:0] of MCi_STATUS is used for indicating
> +		 * a memory-specific error. Note that this field encodes info-
> +		 * rmation about memory-hierarchy level involved in the error.
> +		 */
> +		return (m->status & 0xff00) == BIT(8);

Grrr, you copied this from a patch of mine, correct?

So if you copy it why did you go and change it up and break it on top of
that?! Testing bit 8 is wrong!

NAK!

Before you go and "fix" this again, wait for me to clear up something
else before you even go do that. I'll let you know.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/