linux-kernel - Re: [PATCH 0/6] Add a per-dimm structure

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: <4F61496D.8030000@redhat.com>
Date:	Wed, 14 Mar 2012 22:44:13 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Greg KH <gregkh@...uxfoundation.org>,
	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/6] Add a per-dimm structure

Em 14-03-2012 19:31, Borislav Petkov escreveu:
> On Wed, Mar 14, 2012 at 01:43:55PM -0700, Greg KH wrote:
>>> He thinks that a multi-layer struct should be created inside that directory
>>> (it could have 2 or 3 levels of directories, depending on how the memory is
>>> organized at the memory controller), instead of having a large number of files
>>> there.
>>
>> Why create subdirs?  If those subdirectories are not real devices,
>> showing a real hierarchy, then do not create them as userspace will get
>> very confused very quickly.
> 
> Why, IMO, we agreed on the following layout
> 
> rank0/
> |-- dimm_dev_type
> |-- dimm_edac_mode
> |-- dimm_label
> |-- dimm_location
> |-- dimm_mem_type
> |-- CE
> |-- UE
> `-- dimm_size
> 
> with CE being the correctable errors counter and UE be optional and only
> present when it makes sense for the hardware.

As I said, that is easy to implement. The hard part would be what to do with
the per-csrow/per-branch error counters that exist currently at EDAC.

>From my side, I'm OK to remove them, but, as I said before, existing user tools
use them, especially because UE errors aren't per-rank/per-dimm on the
typical case (128 bits cacheline).

Of course, the EDAC logic could increment multiple UE error counters in such
case, (meaning that an error happened on either one of the affected DIMMs/Ranks)
but this is a different behavior than the current API.

Regards,
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/