linux-kernel - Re: [PATCH] mce: fix warning messages about static struct mce

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:	Thu, 19 Jan 2012 13:28:12 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Greg KH <gregkh@...e.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Sergei Trofimovich <slyich@...il.com>,
	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>,
	Linux PM mailing list <linux-pm@...r.kernel.org>,
	Tony Luck <tony.luck@...el.com>,
	Borislav Petkov <bp@...64.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	prasad@...ux.vnet.ibm.com, Ming Lei <tom.leiming@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Borislav Petkov <borislav.petkov@....com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	Andi Kleen <ak@...ux.intel.com>,
	gouders@...bocholt.fh-gelsenkirchen.de,
	Marcos Souza <marcos.mage@...il.com>, justinmattock@...il.com,
	Jeff Chua <jeff.chua.linux@...il.com>
Subject: Re: [PATCH] mce: fix warning messages about static struct mce_device


* Greg KH <gregkh@...e.de> wrote:

> On Wed, Jan 18, 2012 at 10:31:38AM +0100, Ingo Molnar wrote:
> > 
> > * Greg KH <gregkh@...e.de> wrote:
> > 
> > > On Tue, Jan 17, 2012 at 09:38:43AM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Greg KH <gregkh@...e.de> wrote:
> > > > 
> > > > > diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
> > > > > index f35ce43..6aefb14 100644
> > > > > --- a/arch/x86/include/asm/mce.h
> > > > > +++ b/arch/x86/include/asm/mce.h
> > > > > @@ -151,7 +151,7 @@ static inline void enable_p5_mce(void) {}
> > > > >  
> > > > >  void mce_setup(struct mce *m);
> > > > >  void mce_log(struct mce *m);
> > > > > -DECLARE_PER_CPU(struct device, mce_device);
> > > > > +extern struct device *mce_device[CONFIG_NR_CPUS];
> > > > 
> > > > Minor nit, i don't think we have any other such [CONFIG_NR_CPUS] 
> > > > pattern in the kernel.
> > > > 
> > > > This should be something like:
> > > > 
> > > >   DECLARE_PER_CPU(struct device *, mce_device);
> > > 
> > > That is what we used to have, but with just a static struct 
> > > device. [...]
> > 
> > Which was fine in itself for a per CPU data structure - 
> > wouldnt the warning be fixed by memset()-ing before 
> > registering the device or such, if device registry 
> > absolutely needs a pre-zeroed buffer?
> 
> It was already fixed that way, but the problem is that you can 
> not have statically allocated 'struct device' objects in the 
> system. [...]

Where does that limitation come from? Typically there's no 
fundamental reason why there should be such restrictions in 
place, but i might be missing something.

Although one could argue that *this* particular bug is evidence 
why static allocations should be disallowed: reuse is way too 
easy to mess up :-)

> > I don't object to the quick fix that gets rid of the 
> > warnings, but that quick fix came at the price of leaving 
> > the real bug unfixed and at the price of introducing a new 
> > ugliness ;-)
> 
> Nope, all of the bugs are now fixed :)

Okay :-)

> > > [...] We really don't need this to be in the per-cpu area, 
> > > a flat array should be just fine, why can't we use the 
> > > CONFIG_NR_CPUS value?  Should we use something else?
> > 
> > By that argument we don't really need PER_CPU() areas to 
> > begin with, a flat [CONFIG_NR_CPUS] array is just fine, 
> > right?
> 
> I never said that, only for this type of variable.

There's nothing unusual about this: a percpu array of pointers 
occurs in dozens of places in the kernel.

> > Would be nice if you could do that or some other equivalent 
> > solution, i'd really not like to see the [CONFIG_NR_CPUS] 
> > pattern to spread in the kernel, we spent a lot of time 
> > getting rid of such uses ;-)
> 
> Ok, I'll work on resolving this.

Thanks!

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