linux-kernel - Re: [PATCH 20/21] amd64_edac: add DRAM error injection logic using sysfs

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>] [day] [month] [year] [list]

Message-ID: <37726.64726.qm@web50105.mail.re2.yahoo.com>
Date:	Thu, 30 Apr 2009 06:55:32 -0700 (PDT)
From:	Doug Thompson <norsk5@...oo.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Borislav Petkov <borislav.petkov@....com>,
	akpm@...ux-foundation.org, greg@...ah.com, tglx@...utronix.de,
	hpa@...or.com, dougthompson@...ssion.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 20/21] amd64_edac: add DRAM error injection logic using sysfs


--- On Thu, 4/30/09, Ingo Molnar <mingo@...e.hu> wrote:

> From: Ingo Molnar <mingo@...e.hu>
> Subject: Re: [PATCH 20/21] amd64_edac: add DRAM error injection logic using sysfs
> To: "Doug Thompson" <norsk5@...oo.com>
> Cc: "Borislav Petkov" <borislav.petkov@....com>, akpm@...ux-foundation.org, greg@...ah.com, tglx@...utronix.de, hpa@...or.com, dougthompson@...ssion.com, linux-kernel@...r.kernel.org
> Date: Thursday, April 30, 2009, 2:34 AM
> 
> * Doug Thompson <norsk5@...oo.com>
> wrote:
> 
> > 
> > I believe I failed to reply to ALL and replied only to
> the sender
> > 
> > doug t
> > 
> > --- On Wed, 4/29/09, Ingo Molnar <mingo@...e.hu>
> wrote:
> > 
> > > From: Ingo Molnar <mingo@...e.hu>
> > > Subject: Re: [PATCH 20/21] amd64_edac: add DRAM
> error injection logic using sysfs
> > > To: "Borislav Petkov" <borislav.petkov@....com>
> > > Cc: akpm@...ux-foundation.org,
> greg@...ah.com, tglx@...utronix.de,
> hpa@...or.com, dougthompson@...ssion.com,
> linux-kernel@...r.kernel.org
> > > Date: Wednesday, April 29, 2009, 12:17 PM
> > > 
> > > * Borislav Petkov <borislav.petkov@....com>
> > > wrote:
> > > 
> > > > From: Doug Thompson <dougthompson@...ssion.com>
> > > > 
> > > > Signed-off-by: Doug Thompson <dougthompson@...ssion.com>
> > > > Signed-off-by: Borislav Petkov <borislav.petkov@....com>
> > > > ---
> > > >  drivers/edac/amd64_edac.c |  287
> > > +++++++++++++++++++++++++++++++++++++++++++++
> > > >  1 files changed, 287 insertions(+), 0
> > > deletions(-)
> > > > 
> > > > diff --git a/drivers/edac/amd64_edac.c
> > > b/drivers/edac/amd64_edac.c
> > > > index b1a7e8c..4d1076f 100644
> > > > --- a/drivers/edac/amd64_edac.c
> > > > +++ b/drivers/edac/amd64_edac.c
> > > > @@ -4621,3 +4621,290 @@ static ssize_t
> > > amd64_hole_show(struct mem_ctl_info *mci, char
> *data)
> > > >  
> > > >  #endif    /* DEBUG */
> > > >  
> > > > +#ifdef
> CONFIG_EDAC_AMD64_OPTERON_ERROR_INJECTION
> > > 
> > > this should be in a separate .c file under
> > > drivers/edac/amd64/. 
> > > 
> > > Introducing large #ifdef sections like that is
> not very
> > > clean. The 
> > > amd64_edac.c file is _way_ too large at more than
> 5000
> > > lines of 
> > > code.
> > > 
> > >     Ingo
> > 
> > If we broke this into a separate files, then there
> would be TWO 
> > (2) files: 1 for the source code of the routines and a
> 1 for the 
> > table entries which reference those routines. Is that
> then 
> > acceptable as well?
> > 
> > Same pattern applies to the DEBUG functions Info
> refers to in 
> > another thread: 2 separate files would be required as
> well.
> > 
> > 2 files for Error Injection code
> > 2 files for DEBUG controls
> > 1 files for text mapping
> > 
> > and I assume all these would be included via an
> #include statement 
> > at their appropriate locations
> 
> A Makefile might be more natural i think - that way the
> #ifdef turns 
> into a makefile rule?
> 
>     Ingo
> 

OK, yes for the separate and standalone functions themselves, but NOT for the function pointer table entries, which also share the table with the DEBUG function pointers and possibly function pointers to code that is not bracketed by #ifdefs 

The function pointer table itself is/can be composed of several entries, not just of the injection or debug kind. In this instance, that is what is there, but I would prefer to allow for future additions not tied to injection and/or debug origins nor of #ifdef bracketing

doug t

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