linux-kernel - Re: [tip:x86/mce] x86, mce: Rename cpu_specific_poll to mce_cpu_specific

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: <4B856500.9030108@infradead.org>
Date:	Wed, 24 Feb 2010 14:42:24 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Borislav Petkov <petkovbb@...glemail.com>, mingo@...hat.com,
	hpa@...or.com, linux-kernel@...r.kernel.org, andi@...stfloor.org,
	tglx@...utronix.de, Andreas Herrmann <andreas.herrmann3@....com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	linux-tip-commits@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Aristeu Rozanski <aris@...hat.com>,
	Doug Thompson <norsk5@...oo.com>,
	Huang Ying <ying.huang@...el.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [tip:x86/mce] x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll

Mauro Carvalho Chehab wrote:
> The EDAC data model needs some discussion, as, currently, the memory is represented 
> per csrow, and modern MCU don't allow such level of control (and it doesn't 
> make much sense on representing this way, as you can't replace a csrow). The 
> better is to use DIMM as the minumum unit.

Just to start the data model, this is what a typical EDAC driver presents:

/sys/devices/system/edac/mc/mc0/                                                
|-- ce_count                                                                    
|-- ce_noinfo_count                                                             
|-- csrow0
|   |-- ce_count
|   |-- ch0_ce_count
|   |-- ch0_dimm_label
|   |-- ch1_ce_count
|   |-- ch1_dimm_label
|   |-- ch2_ce_count
|   |-- ch2_dimm_label
|   |-- ch3_ce_count
|   |-- ch3_dimm_label
|   |-- dev_type
|   |-- edac_mode
|   |-- mem_type
|   |-- size_mb
|   `-- ue_count
|-- csrow1                                                                      
|   |-- ce_count
|   |-- ch0_ce_count
|   |-- ch0_dimm_label
|   |-- ch1_ce_count
|   |-- ch1_dimm_label
|   |-- ch2_ce_count
|   |-- ch2_dimm_label
|   |-- ch3_ce_count
|   |-- ch3_dimm_label
|   |-- dev_type
|   |-- edac_mode
|   |-- mem_type
|   |-- size_mb
|   `-- ue_count
|-- device -> ../../../../pci0000:3f/0000:3f:03.0                               
|-- mc_name                                                                     
|-- reset_counters                                                              
|-- sdram_scrub_rate                                                            
|-- seconds_since_reset                                                         
|-- size_mb                                                                     
|-- ue_count                                                                    
`-- ue_noinfo_count                                                             

In the case of i7core_edac, there's no way to identify csrows by using
the public registers (I've no idea is is there any non-documented register
for it). So, the driver maps one dimm per "edac csrow".

It would be good to see a better struct for it.

With respect to error injection, this is the way i7core maps it:

|-- inject_addrmatch                                                            
|   |-- bank                                                                    
|   |-- channel                                                                 
|   |-- col                                                                     
|   |-- dimm                                                                    
|   |-- page                                                                    
|   `-- rank                                                                    
|-- inject_eccmask                                                              
|-- inject_enable                                                               
|-- inject_section                                                              
|-- inject_type                                                                 

The inject_addrmatch leaves control a match filter for the error
where the error will be inject. I doubt we would find a way to standardize it.

Cheers,
Mauro
--
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/