linux-kernel - Re: [RFC PATCH 1/4] RAS: Add a Corrected Errors Collector

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]

Message-ID: <20160607210427.GF1152@pd.tnic>
Date:	Tue, 7 Jun 2016 23:04:27 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	linux-edac <linux-edac@...r.kernel.org>,
	Yazen Ghannam <Yazen.Ghannam@....com>, X86 ML <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/4] RAS: Add a Corrected Errors Collector

On Tue, Jun 07, 2016 at 11:11:09AM -0700, Luck, Tony wrote:
> Is there a reason that we need to call the ce_add_elem() inline
> here instead of having it just register on the mce_notifier chain?
> This series just cleaned out all the /dev/mcelog special code from
> here, and you are adding something back before the ink is dry on
> that change.
> 
> I'm also strongly divided about whether this corrected error
> handler should be allowed to preempt anything else even seeing
> the error.

Well, so this is the main reason for adding the CEC: not to disturb
users with random CECC errors which might happen a couple of times
due to alpha particles and then never again. I.e., address all those
sporadic bursts of correctable errors which don't mean that the hw is
going faulty.

If the CEC consumes the error and does the leaky bucket of "forgetting"
about it after a while and after no more of that same PFN triggers
errors, then we do that silently and do not scare users. Yeah, they
think their hw is broken and whether they should start swapping things.

And then there's the aspect of soft-offlining PFNs when the error
threshold has been reached. I don't think we have had any automatic
recovery actions wrt errors so far without external agents.

> Argument for:
> Lonely corrected errors are "No Big Deal"(TM). Just counting them
> and moving on is a good thing.

Yap, exactly.

> Arguments against:
> 1) We may miss out on a one-time opportunity to get extra information
> (from acpi_extlog.c).
> 2) I think this subverts our CMCI storm detection and mitigation code?

...and we can address that by adding "ras=cec_doesnt_consume_errors" or
somesuch so that the rest of the chain sees them too.

I think we can be pretty flexible about it. And again, my main angle is
the "do not disturb users unnecessarily".

> We could make the chain more caller friendly by adding a filter
> argument so users could say "just tell me about memory errors"
> (currently each of the EDAC drivers has inline code to do the same
> as "memory_error(m) && mce_usable_address(m)")

Sure, that too.

And it can work on any system without the need for an EDAC driver.

Thanks.

-- 
Regards/Gruss,
    Boris.

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