linux-kernel - Re: sysfs: cannot create duplicate filename

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: <alpine.LFD.2.02.1104111943590.2036@c4eb>
Date:	Mon, 11 Apr 2011 19:50:34 +0200 (CEST)
From:	Sebastian Ott <sebott@...ux.vnet.ibm.com>
To:	Greg KH <gregkh@...e.de>
cc:	linux-kernel@...r.kernel.org
Subject: Re: sysfs: cannot create duplicate filename



On Mon, 11 Apr 2011, Greg KH wrote:

> On Mon, Apr 11, 2011 at 05:05:08PM +0200, Sebastian Ott wrote:
> > 
> > 
> > On Mon, 11 Apr 2011, Greg KH wrote:
> > 
> > > On Mon, Apr 11, 2011 at 04:33:03PM +0200, Sebastian Ott wrote:
> > > > On Mon, 11 Apr 2011, Greg KH wrote:
> > > > 
> > > > > On Mon, Apr 11, 2011 at 04:04:08PM +0200, Sebastian Ott wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > i've seen this warning which looks to be caused by a race between device_add
> > > > > > and driver_register
> > > > > > 
> > > > > > [   80.893594] sysfs: cannot create duplicate filename '/bus/ccw/drivers/qeth/0.0.b57d'
> > > > > 
> > > > > Isn't the problem here the fact that you are creating 2 directories of
> > > > > the same name?
> > > > I'm sure this isn't the case here. The bus code just calls device_add and
> > > > at the same time on a different thread a module is loaded which registers
> > > > a driver at the bus.
> > > > 
> > > > I was able to reproduce this with a module which creates a dummy bus
> > > > and registers drivers and devices on this bus on 2 different workqueues.
> > > 
> > > That makes sense, as no bus should be doing this on multiple "threads".
> > > What real-life bus does this today?
> > A bus that will recognize and register a lot of devices, after the first
> > uevent is presented to userspace, a module will be loaded registering a
> > driver from a different thread. I don't think thats uncommon.
> 
> But again, what kernel code today does this?  I think they all have
> locks to keep this from happening, right?
I couldn't find a bus who protects device_register against driver_register
and I don't think this is something which should be handled by every
individual bus but from within the driver core.

> 
> > > > > > * device_add attached the device to the bus /*break*/
> > > > > > * driver_register walks the list of devices and tries to bind
> > > > > >   unbound devices
> > > > > > * /*continue*/ device_add calls device_attach which gets confused
> > > > > >   that the device is already bound to a driver
> > > > > 
> > > > > Why would your bus code ever allow this to happen?  It's the caller's
> > > > > responsiblity to do things in the correct order, right?
> > > > I don't think the bus code which calls device_register can (or should)
> > > > prevent drivers from beeing registered at this bus at the same time.
> > > 
> > > Why not?  That's the way all kernel subsystems work today that I know
> > > of.  Has this changed?
> > What about an exported bus_type? At all time a driver for this bus can
> > be registered, the bus code has no chance to prevent or serialize this.
> 
> No, the bus core is the one that should be binding the bus type to the
> driver and doing the registering.  No individual driver should ever be
> messing with a bus_type at all.
> 
> Now perhaps platform devices are, and if so, we might want to resolve
> this, but no "real" bus should ever be doing this.
> 
> 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/