linux-kernel - Re: Hardware Error Kernel Mini-Summit

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: <AANLkTilxFZygP7YJybluPxtdxVGqWeqR4g7CRr8EEocW@mail.gmail.com>
Date:	Wed, 19 May 2010 10:30:17 -0700
From:	Tony Luck <tony.luck@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Borislav Petkov <bp@...64.org>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	"Young, Brent" <brent.young@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Matt Domsch <Matt_Domsch@...l.com>,
	Doug Thompson <dougthompson@...ssion.com>,
	Joe Perches <joe@...ches.com>, Ingo Molnar <mingo@...e.hu>,
	"bluesmoke-devel@...ts.sourceforge.net" 
	<bluesmoke-devel@...ts.sourceforge.net>,
	Linux Edac Mailing List <linux-edac@...r.kernel.org>
Subject: Re: Hardware Error Kernel Mini-Summit

On Tue, May 18, 2010 at 6:14 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> A log is a fine format for realizing you have a problem.  A
> log doesn't need to be the only place errors are reported
> but a log should be the default place ECC errors are reported.
> We do that with hard drive errors and other kinds of hardware
> errors and we have done it for years without problems.

Hard drives aren't really a similar situation ... we don't see any
of the low level errors from a modern hard drive because its
f/w handles the retries and block re-mapping transparently.
By the time something serious enough happens that it gets
reported to the OS, we pretty much already know that there
is a real problem.

We are still in the dark ages for memory errors where the OS
is expected to look at all the errors and figure out whether they
represent any kind of meaningful pattern that requires some
action to replace h/w components.

-Tony
--
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/