linux-kernel - Re: udev races with 'arch_register_cpu' to write 1 to /sys/devices/system/cpu/cpu1/online (which is not yet created)

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: <20130513142532.GA15808@kroah.com>
Date:	Mon, 13 May 2013 07:25:32 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	Igor Mammedov <imammedo@...hat.com>, chuck.anderson@...cle.com,
	linux-kernel@...r.kernel.org
Subject: Re: udev races with 'arch_register_cpu' to write 1 to
 /sys/devices/system/cpu/cpu1/online (which is not yet created)

On Mon, May 13, 2013 at 09:31:28AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 10, 2013 at 06:34:34PM +0200, Igor Mammedov wrote:
> > >On Mon, Apr 30, 2012 at 11:51:49AM -0400, Greg KH wrote:
> > >> On Mon, Apr 30, 2012 at 11:50:18AM -0400, Greg KH wrote:
> > >> > On Mon, Apr 30, 2012 at 11:36:23AM -0400, Konrad Rzeszutek Wilk wrote:
> > >> > > Hey Greg,
> > >> > > 
> > >> > > Hoping you can help with some guidance on how to fix this.
> > >> > > 
> > >> > > The issue is with CPU hotplug is that when a CPU goes up
> > >> > > it calls 'arch_register_cpu' which eventually calls
> > >> > > register_cpu. That function does these two things:
> > >> > > 
> > >> > > 251         error = device_register(&cpu->dev);
> > >> > > 252         if (!error && cpu->hotpluggable)
> > >> > > 253                 register_cpu_control(cpu);
> > >> > > 
> > >> > > and the device_register creates a nice little SysFS directory:
> > >> > > 
> > >> > > /sys/devices/system/cpu/cpu2/ which at line 251 has the 'add' attribute
> > >> > > but no 'online' attribute. udev then tries to echo 1 to the 'online'
> > >> > > and it we get:
> > >> > > udevd-work[2421]: error opening ATTR{/sys/devices/system/cpu/cpu2/online} for writing: No such file or directory
> > >> > > 
> > >> > > Line 253 creates said 'online' and at that time udev [or the system admin]
> > >> > > can write 1 to 'online' and the CPU goes up.
> > >> > > 
> > >> > > So .. any thoughts? Is there some way to inhibit from uevent being sent
> > >> > > until line 253 has run?
> > >> > 
> > >> > Yes.
> > >> 
> > >> Oh, I imagine you want to know _how_ to do it too, right?  (sorry, I
> > >> couldn't resist...)
> > >
> > >Heh.
> > >> 
> > >> Make this a default attribute of the cpu device, and then it will be
> > >> created by the driver core before the uevent is sent to userspace.
> > >> That's what you are supposed to do in the first place, adding files "by
> > >> hand" is wrong, for this very reason.
> > >
> > >OK, will prep up a patch shortly.
> > 
> > Hello Konrad,
> > 
> > Is there a posted/accepted patch or idea was dropped?
> 
> Hey Igor,
> 
> CC-ing here Chuck here who is looking at that. My recollection (and Chuck please
> correct me if I am wrong) is that the idea Greg outlined won't work very well.
> The reason is that making 'online' an attribute of 'struct dev' means that:
>  1) A lot of SysFS attributes that have no notion of online/offline (say ISA bus)
>     will now have.

Then only create that attribute for busses that ask for it to be enabled.

>  2) The default action item (so function) to do something based on
>  writting/reading from 'online' will have to be overridden by the
>  driver using it. Which means another race - we can create an SysFS
>  attribute but the default points to something that does nothing.

I don't understand this at all, how will there be a race exactly?

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/