| 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
| ||
|
Message-ID: <20111209191819.GA17086@aftab> Date: Fri, 9 Dec 2011 20:18:19 +0100 From: Borislav Petkov <bp@...64.org> To: "Luck, Tony" <tony.luck@...el.com> Cc: Borislav Petkov <bp@...64.org>, LKML <linux-kernel@...r.kernel.org>, X86-ML <x86@...nel.org>, EDAC devel <linux-edac@...r.kernel.org> Subject: Re: [PATCH 2/2] x86, MCE: Drain mcelog buffer On Fri, Dec 09, 2011 at 10:40:10AM -0800, Luck, Tony wrote: > > Do you see a usecase for multiple consumers? > > Only a theoretical one ... we might have a cpu model specific decoder > and an OEM supplied platform decoder - each as an independent module. Well, off the top of my head, we could probably _not_ delete the already logged MCEs (bool keep arg, or similar) and when the last one registers, it passes keep=false and cleans them up. And since we probably know which one is the last - order is enforced by the initcalls order - we're done. However, is the platform module using MCA at all or will it probably use PCIe AER instead? Also, at the time the platform module inits, we've already regged the CPU decoders so we can go ahead and safely delete the logged MCEs. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- 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/
Powered by blists - more mailing lists