linux-kernel - Re: x86/mce merge, integration hickup + crash, design thoughts

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: <20081230212903.GB19653@sgi.com>
Date:	Tue, 30 Dec 2008 15:29:03 -0600
From:	Russ Anderson <rja@....com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andi Kleen <ak@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Russ Anderson <rja@....com>
Subject: Re: x86/mce merge, integration hickup + crash, design thoughts

On Sat, Dec 27, 2008 at 04:50:19PM +0100, Ingo Molnar wrote:
> 
> If we want to enable userspace to capture MCE events, then it must be done 
> in a way that benefits the whole kernel, not just x86: a structured 
> logging facility that is in essence a printk variant and is ASCII driven. 

It would be very useful to implement error handling in a way
that has an arch independed framework.  ia64 has already
implemented much of this functionality.

> Such event sources should be discoverable, and only 'aware' printouts 
> should go into this new facility (not all printks). Demultiplexing should 
> be easy and well-defined.
> 
> I.e. we could use this opportunity of the MCE code unification to bring 
> the code to the next level - and not prolongue to broken concepts of the 
> past.
> 
> I'd be glad to help out with any portion of this, it should be easy to 
> solve and it will clearly improve the code. For .29 we could just do a raw 
> printk based approach with no decoding just yet, and layer smart decoding 
> and structured logging for .30.
> 
> Hm?

Something along those lines, though I would support more of
Andi's code getting in for .29 (even if it means putting code
into .29 and then changing it for .30).  It will take time to
come up with a cross arch framework, longer than the .29
merge window.

Thanks,
-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@....com
--
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/