Re: sysfs: cannot create duplicate filename

[Greg KH]

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?

> > > > > * 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/