linux-kernel - Re: [PATCH v2 2/2] mce: acpi/apei: Add a boot option to disable ff mode for corrected errors

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: <20130619201438.GM28300@pd.tnic>
Date:	Wed, 19 Jun 2013 22:14:38 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
	"ananth@...ibm.com" <ananth@...ibm.com>,
	"masbock@...ux.vnet.ibm.com" <masbock@...ux.vnet.ibm.com>,
	"lcm@...ux.vnet.ibm.com" <lcm@...ux.vnet.ibm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"Huang, Ying" <ying.huang@...el.com>
Subject: Re: [PATCH v2 2/2] mce: acpi/apei: Add a boot option to disable ff
 mode for corrected errors

On Wed, Jun 19, 2013 at 07:05:16PM +0000, Luck, Tony wrote:
> > Why, fill out struct mce and do mce_log(mce) does not suffice?
> 
> There is (or should be)

Ha!

> a lot more interesting stuff in the CPER than just the address. Stuff
> that we don't have fields for in the existing mcelog structure. We
> also need to treat filtered records from modern APEI implementations a
> bit differently from the old stuff.

Great, the CPER record is described in the UEFI spec. Those BIOS people
are all like a mafia.

Ok, seriously: so the situation should still be fine, FF reported errors
get the CPER format while the rest, the "old" MCE format.

cper.c is doing printk so I'm guessing it would need to get its own
tracepoint and carry that to userspace.

Concerning the RAS daemon, Robert and I are making good progress so once
we have the persistent events in perf, we can read that tracepoint in
userspace and do whatever we want with the error info.

> The original user of this code was Westmere-EX, which used it as a
> workaround for a missing address in MCi_ADDR for corrected errors.
> So in that scenario we had every error being reported and mcelog(8)
> deamon doing the threshold analysis to decide when to take action.
>
> In this new modern world - Naveen wants to have the BIOS decide the
> threshold, so we'd like Linux to take some action as soon as it sees
> just one CPER.

Why would Linux have to intervene if it is doing FF - wasn't the deal
behind Firmware First for the firmware to get the error first and handle
accordingly?

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