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: <4F6147E8.3020409@redhat.com>
Date:	Wed, 14 Mar 2012 22:37:44 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	Borislav Petkov <bp@...64.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:40, Greg KH escreveu:
> On Wed, Mar 14, 2012 at 11:31:02PM +0100, Borislav Petkov wrote:
>> 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.
>>
>> This is not multi-layered, it is very easy to implement and mirrors all
>> possible memory controllers from the point of view of the single DIMM.
>> no? Or am I missing something...?
> 
> Looks fine to me, assuming "rankX" is the dimm itself?

The node name can be either "rankX" or "dimmX", depending if the memory controller
is able to detect wich memory ranks belong to each DIMM or not.

> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-edac" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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