Messages in this thread | | | Date | Mon, 11 Apr 2011 19:50:34 +0200 (CEST) | From | Sebastian Ott <> | 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 >
| |