Re: Flaw in the driver-model implementation of attributes

[Alan Stern]

On Mon, 16 Jun 2003, Russell King wrote:

> On Mon, Jun 16, 2003 at 10:08:26AM -0700, Greg KH wrote:
> > Then don't let your module unload until _all_ instances of your
> > structures are gone.  You can tell if this is true or not, it's just up
> > to the implementor :)
> 
> Greg, I believe Alan does have a valid concern.  Eg, how is the following
> handled?
> 
> - PCI device driver module is loaded
> - device driver gets handed a pci device
> - device driver attaches a file to the struct device corresponding to the
>   PCI device.
> - userspace opens new file (this does not increment the device drivers
>   use count.)
> - device driver is rmmod'd
> - device driver removes its references to the pci device
> - device driver unloads
> - user reads from opened file.

Thank you, that was exactly my point.  Opening the file increments the 
device's refcount but not the driver's.

> > Look at the new pcmcia code for just such an example.
> 
> In the pcmcia case, we effectively own the object (class device) we're
> attaching the files to, so we can ensure that the module is not unloaded
> until the class device files are closed and all references to the object
> are gone.
> 
> IMO, if you don't own the object (and therefore don't know its lifetime),
> you shouldn't be adding sysfs or device model attributes of any kind to
> that object.

That's not practical.  How else can a device driver provide 
device-specific configuration options or information in sysfs?  In many 
cases the device is owned by the bus, not the device driver.

By the way, both the EHCI and OHCI host controller drivers do this.  It's 
easy to cause an oops by delaying a read of (for example) the "periodic" 
file they create until after the driver is unloaded.

Alan Stern