linux-kernel - RE: [Patch V1 1/3] x86, mce: MCE log size not enough for high core parts

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Sep 2015 18:44:25 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Borislav Petkov <bp@...en8.de>, "Raj, Ashok" <ashok.raj@...el.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: RE: [Patch V1 1/3] x86, mce: MCE log size not enough for high core
 parts

> Now that we have this shiny 2-pages sized lockless gen_pool, why are we
> still dealing with struct mce_log mcelog? Why can't we rip it out and
> kill it finally? And switch to the gen_pool?
>
> All code that reads from mcelog - /dev/mcelog chrdev - should switch to
> the lockless buffer and will iterate through the logged MCEs there.

I think we have a problem of when to delete entries ... we can only do that
when all the interested consumers of logs have seen an entry. But we have
no control in the kernel on consumption from /dev/mcelog.

Historic semantics was that the first MCE_LOG_LEN errors would sit
in the buffer waiting for userspace to begin running a daemon to read
them.

-Tony