linux-kernel - Re: [PATCH 0/2] Generic hardware error reporting support

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:	Sun, 21 Nov 2010 07:44:36 +0800
From:	huang ying <huang.ying.caritas@...il.com>
To:	Mark Lord <kernel@...savvy.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Huang Ying <ying.huang@...el.com>, Len Brown <lenb@...nel.org>,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
	linux-acpi@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/2] Generic hardware error reporting support

On Sat, Nov 20, 2010 at 9:39 PM, Mark Lord <kernel@...savvy.com> wrote:
> On 10-11-20 02:11 AM, huang ying wrote:
>>
>> I think the BIOS error should be reported to hardware vendor instead
>> of software vendor. Do you think so?
>
> If you (and the code) are absolutely certain that a particular error
> instance
> is totally due to the BIOS, then stick the words "BIOS ERROR" into the
> printk().
>
> Problem solved.
>
> And in the even that the diagnosis is wrong, the rest of us will still
> have the complete picture of what happened from dmesg, rather than seeing
> random kernel errors (from other code) happen later without knowing there
> was some kind of BIOS or hardware fault that triggered it.
>
> Having them all in one place is rather useful.
> And you can still configure rsyslogd to _also_ send the BIOS/hardware
> errors to a separate destination, if that turns out to be useful.

I have no objection to report hardware errror with printk too. But we
need a user space hardware error daemon too, which needs a
tool-oriented interface. Do you think printk is a good interface for
tool to extract and parse error records? I think it is mainly human
oriented.

Best Regards,
Huang Ying
--
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/