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:	Tue, 17 Jan 2012 07:52:10 -0800
From:	Greg KH <gregkh@...e.de>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	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>,
	"mingo@...e.hu" <mingo@...e.hu>, 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>, neilb@...e.de
Subject: Re: [PATCH] mce: fix warning messages about static struct mce_device

On Tue, Jan 17, 2012 at 06:06:35PM +0530, Srivatsa S. Bhat wrote:
> On 01/17/2012 04:10 AM, Greg KH wrote:
> 
> > From: Greg Kroah-Hartman <gregkh@...e.de>
> > 
> > When suspending, there was a large list of warnings going something like:
> > 
> > 	Device 'machinecheck1' does not have a release() function, it is broken and must be fixed
> > 
> > This patch turns the static mce_devices into dynamically allocated, and
> > properly frees them when they are removed from the system.  It solves
> > the warning messages on my laptop here.
> >
> 
> ...
> 
> >  /* Per cpu device init. All of the cpus still share the same ctrl bank: */
> >  static __cpuinit int mce_device_create(unsigned int cpu)
> >  {
> > -	struct device *dev = &per_cpu(mce_device, cpu);
> > +	struct device *dev;
> >  	int err;
> >  	int i, j;
> > 
> >  	if (!mce_available(&boot_cpu_data))
> >  		return -EIO;
> > 
> > -	memset(dev, 0, sizeof(struct device));
> > +	dev = kzalloc(sizeof *dev, GFP_KERNEL);
> > +	if (!dev)
> > +		return -ENOMEM;
> >  	dev->id  = cpu;
> >  	dev->bus = &mce_subsys;
> > +	dev->release = &mce_device_release;
> > 
> >  	err = device_register(dev);
> >  	if (err)
> > @@ -2030,6 +2038,7 @@ static __cpuinit int mce_device_create(unsigned int cpu)
> >  			goto error2;
> >  	}
> >  	cpumask_set_cpu(cpu, mce_device_initialized);
> > +	mce_device[cpu] = dev;
> > 
> >  	return 0;
> >  error2:
> > @@ -2046,7 +2055,7 @@ error:
> > 
> >  /* Make sure there are no machine checks on offlined CPUs. */
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c
> > index ba0b94a..786e76a 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
> > @@ -523,6 +523,7 @@ static __cpuinit int threshold_create_bank(unsigned int cpu, unsigned int bank)
> >  {
> >  	int i, err = 0;
> >  	struct threshold_bank *b = NULL;
> > +	struct device *dev = mce_device[cpu];
> >  	char name[32];
> > 
> >  	sprintf(name, "threshold_bank%i", bank);
> > @@ -543,8 +544,7 @@ static __cpuinit int threshold_create_bank(unsigned int cpu, unsigned int bank)
> >  		if (!b)
> >  			goto out;
> > 
> > -		err = sysfs_create_link(&per_cpu(mce_device, cpu).kobj,
> > -					b->kobj, name);
> > +		err = sysfs_create_link(&dev->kobj, b->kobj, name);
> 
> 
> I don't think dereferencing 'dev' like this is safe when booting up.
> (See below for another such instance of dereferencing dev.)
> 
> Both mcheck_init_device() and threshold_init_device() are device_initcalls.
> And the latter depends on the former, because the former dynamically
> allocates and fills the 'mce_device' array of pointers.
> 
> So, what guarantees that this ordering is preserved? IOW, what ensures that
> mcheck_init_device() is completed before running threshold_init_device()?
> 
> Or am I missing something?

You must be, as this is the way it is always works, and somehow your
machine boots properly, with the symlinks setup :)

thanks,

greg k-h
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ