linux-kernel - Re: [PATCH 3/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] [day] [month] [year] [list]

Message-ID: <20170324110917.jh7zoixdfop6axiz@pd.tnic>
Date:   Fri, 24 Mar 2017 12:09:17 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     X86 ML <x86@...nel.org>, linux-edac <linux-edac@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/4] RAS: Add a Corrected Errors Collector

On Thu, Mar 23, 2017 at 11:20:44AM -0700, Luck, Tony wrote:
> Keeping every PFN would be overkill (most of them should be taken
> offline with no issues).  A fixed array of a few of them with timestamps
> to drop the oldest would likely be a good enough(TM) solution.

The reason being? Prevent the CEC from adding it and trying to
unsuccessfully offline it again?

If so, that means, we will query that list on every element insertion so
it needs to be something we can search pretty quickly.

> Worst case is pretty ugly. A frequently used kernel page with a stuck
> bit could be added to the CEC array, overflow, and generate a message
> at a pretty high rate.

Oh sure, but it would still be lower rate than generating a message for
*each* correctable error. And I really think that these messages should
*not* be supressed as they're important. The CEC kinda ratelimits them a
bit though...

> Maybe ... but it gets into opinion rather than science. Some folks
> think that very low numbers of corrected errors warrant DIMM replacement.
> Others think that you can keep running almost forever with a several
> stuck bits per DIMM.
> 
> Some of the best decisions would be made by correlating error logs
> from multiple reboots ... which the kernel can't do.

... and maybe even then it doesn't fit everybody's use case.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.