linux-kernel - Re: [PATCH v3 01/31] events/hw_event: Create a Hardware Events Report Mecanism (HERM)

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: <20120213092131.GA7235@aftab>
Date:	Mon, 13 Feb 2012 10:21:31 +0100
From:	Borislav Petkov <bp@...64.org>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
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 v3 01/31] events/hw_event: Create a Hardware Events
 Report Mecanism (HERM)

On Sun, Feb 12, 2012 at 05:38:08PM -0200, Mauro Carvalho Chehab wrote:
> Em 12-02-2012 16:44, Borislav Petkov escreveu:
> > On Sun, Feb 12, 2012 at 03:21:42PM -0200, Mauro Carvalho Chehab wrote:
> >> As I said before, there's just one trace call for memory error events 
> >> (hw_event:mc_error) on my second RFC.
> > 
> > Are you kidding me:
> > 
> > $ grep -EriIno "trace_.*\W" patch01.txt
> > 
> > ...
> > 
> > TRACE_EVENT(mc_corrected_error,
> > TRACE_EVENT(mc_uncorrected_error,
> > TRACE_EVENT(mc_corrected_error_fbd,
> > TRACE_EVENT(mc_uncorrected_error_fbd,
> > TRACE_EVENT(mc_out_of_range,
> > TRACE_EVENT(mc_corrected_error_no_info,
> > TRACE_EVENT(mc_uncorrected_error_no_info,
> > 
> 
> Huh?
> 
> See PATCH v3 03/31:  hw_event: Consolidate uncorrected/corrected error msgs into one
> 
> Those events got merged there into one hardware event and one
> software error event generated due to a hardware trouble
> (mc_out_of_range).

[..]

Right, and what I was suggesting is to introduce a single trace event
and use it everywhere. Instead, you're converting the edac calls into
trace events and then eliminating them, which creates unnecessary noise.

But, nevermind this, I have a better suggestion: instead of you and me
going back and forth needlessly about the trace events, how about you
concentrate on fixing the FBDIMM drivers (and only those) since this is
the main reason for your patchset, as you say, and let me concentrate
on writing the trace event I mean - I'm currently travelling but I'll
try to hack up something in the next couple of days in order to give
you a better idea of what I mean? The edac drivers can use the standard
edac_printk and friends in the meantime and we can convert them later.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/