linux-kernel - Re: [PATCH v2] edac_mc: Cleanup per-dimm

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]

Date:	Mon, 30 Apr 2012 12:33:43 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Doug Thompson <norsk5@...oo.com>, Joe Perches <joe@...ches.com>
Subject: Re: [PATCH v2] edac_mc: Cleanup per-dimm_info debug messages

Em 30-04-2012 12:20, Borislav Petkov escreveu:
> On Mon, Apr 30, 2012 at 12:10:24PM -0300, Mauro Carvalho Chehab wrote:
>>> [  728.430828] EDAC DEBUG: edac_mc_dump_dimm: 	dimm2: channel 0 slot 2 mapped as virtual row 0, chan 2
>>> [  728.430834] EDAC DEBUG: edac_mc_dump_dimm: 	dimm->label = 'mc#0channel#0slot#2'
>>> [  728.430839] EDAC DEBUG: edac_mc_dump_dimm: 	dimm->nr_pages = 0x0
>>> [  728.430846] EDAC DEBUG: edac_mc_dump_dimm: 	dimm->grain = 0
>>> [  728.430850] EDAC DEBUG: edac_mc_dump_dimm: 	dimm->nr_pages = 0x0
>>
>> Hmm... just noticed that, just like the per-csrow register dumps, this routine
>> is called even when empty memories are used (in this case: nr_pages = 0).
>>
>> IMHO, as this is a registers dump, the better is to keep it as-is, but it would
>> be simple to add a test there - and at edac_mc_dump_csrow() - to just dump it
>> when dimm->nr_pages is not 0.
>>
>> What do you think?
> 
> Or even better, test dimm->nr_pages != 0 before calling
> edac_mc_dump_csrow() so that you can save yourself the function call.

Ok, I'll do that.

> Btw, where are the latest versions of your patches so that I can
> continue reviewing them?

The very latest series of patches are always at:
	git://git.infradead.org/users/mchehab/edac.git experimental

The latest version of "[PATCH EDACv16 1/2]edac: Change internal representation to work with layers"

is on one of the replies, and also at:

	http://git.infradead.org/users/mchehab/edac.git/commit/447b7929e633027ffe131f2f8f246bba5690cee7

I won't resend the 28 "foo: convert driver to use the new edac ABI" to the mailing list,
as there were no changes on them, except for a contextual change: 
	the .is_csrow field got renamed to .is_virt_csrow

So, there's no sense on flooding the mailing lists with them again.

The only one that you're likely interested is the amd64_edac one (the first one of the 28 patch
series). This patch were re-sent as PATCH EDACv16 2/2.

The next patch after them is "edac: Remove the legacy EDAC ABI"[1], with also didn't change
(maybe except for contextual changes).

After you review them, I'll re-send the other patches on my queue, probably breaking it into two
or three patch series.

[1] http://git.infradead.org/users/mchehab/edac.git/commit/d1390992c51323802e1ccddfa48b16f0be062621

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/