lkml.org 
[lkml]   [2011]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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
    >


    \
     
     \ /
      Last update: 2011-04-11 19:55    [W:0.056 / U:30.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site