linux-kernel - Re: Re-implement MCE log ring buffer as per-CPU ring buffer

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: <20090422092259.GC18226@elte.hu>
Date:	Wed, 22 Apr 2009 11:22:59 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Huang Ying <ying.huang@...el.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Subject: Re: Re-implement MCE log ring buffer as per-CPU ring buffer


* Huang Ying <ying.huang@...el.com> wrote:

> Re-implement MCE log ring buffer as per-CPU ring buffer for better 
> scalability. Basic design is as follow:

Before changing anything substantial in the MCE code it would be 
necessary to clean up and then unify the 32-bit and 64-bit side of 
the MCE code first. (Which essentially means extending the 
64-bit-only code to 32-bit)

I've put a few cleanup patches into tip:x86/mce2 (warning: there are 
a few broken ones at the tail - so consider it WIP), to help make 
this happen:

 dd98699: x86, mce: print number of MCE banks
 ef319a8: x86, mce: unify
 be0f336: x86, mce: unify, prepare for 32-bit
 90c99b7: x86, mce: prepare unification
 1e1d4f8: x86, mce: prepare mce.h and mce_64.c for unification
 fd6b13f: x86, mce: clean up mce_64.c
 f7f8e03: x86, mce: clean up mce_intel.c
 b19c8ea: x86, mce: unify the Intel thermal interrupt code
 6eade5b: mce: unify Intel thermal init, prepare
 d393769: x86, mce: clean up mce.h
 7bb2efa: x86, mce: clean up winchip.c
 3b94f2b: x86, mce: clean up p5.c
 13a219b: x86, mce: clean up mce_32.c
 e69e307: x86, mce: clean up non-fatal.c
 3b9a5bc: x86, mce: clean up k7.c
 79e1d29: x86, mce: clean up p6.c
 c5fac5b: x86, mce: clean up therm_throt.c
 788a16a: x86, mce: clean up p4.c
 07d7726: x86, mce: clean up mce_amd_64.c
 a6a6958: x86, mce: clean up the sysfs variables namespace
 895f799: x86, mce: clean up the mce_64.c code

these are the more questionable ones in need of restructuring:

 dd98699: x86, mce: print number of MCE banks
 ef319a8: x86, mce: unify
 be0f336: x86, mce: unify, prepare for 32-bit
 90c99b7: x86, mce: prepare unification
 1e1d4f8: x86, mce: prepare mce.h and mce_64.c for unification
 fd6b13f: x86, mce: clean up mce_64.c
 f7f8e03: x86, mce: clean up mce_intel.c
 b19c8ea: x86, mce: unify the Intel thermal interrupt code
 6eade5b: mce: unify Intel thermal init, prepare

... but you get the idea.

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