Messages in this thread | | | Date | Mon, 16 Apr 2007 15:53:31 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [Patch -mm 3/3] RFC: Introduce kobject->owner for refcounting. |
| |
On Mon, 16 Apr 2007, Greg KH wrote:
> On Mon, Apr 16, 2007 at 07:36:27PM +0200, Cornelia Huck wrote: > > Grab and release the module kobject refcount if kobj->owner is set. > > This prevents calls to the release function after the module has > > been unloaded. > > But doesn't this cause reference counts to be grabbed on modules that > don't want them? (like network drivers)?
The refcounts we are talking about will not prevent modules from being unloaded. That is, they won't cause rmmod to fail -- they will simply cause it to wait until the refcount drops to 0. This should happen naturally as a result of the unregistration calls made by the module's exit routine.
(That was the intention, anyway. I haven't yet seen all the parts of Cornelia's patch set, but that's how we discussed it.)
> I don't understand what exactly you are trying to protect from here. > Especially as Tejun just ripped the lifetime rules between sysfs and > kobjects apart.
There are other ways for userspace to acquire references to kernel objects. Think of procfs or debugfs, for example. Or opening a device file.
Consider this example: A user has a pcmcia card containing a USB host controller. He plugs a USB flash drive into the card and mounts a filesystem stored on the flash drive. The mount call increments the module refcount for usb-storage (the owner of the block device containing the filesystem), but it doesn't do anything to the module refcount for the pcmcia driver (I forget its name -- yenta or something like that).
So what happens if the pcmcia driver is unloaded while the filesystem is mounted? What happens when the filesystem is finally unmounted and a release method belonging to the pcmcia driver is called?
The fundamental rule is that whenever you hand out a pointer to a routine living in a module, the receiver has to increment the module's refcount. But the driver core violates this rule all over the place. The most pervasive offender is struct device -- it contains a release() method pointer which often points into a module, but the driver core doesn't do anything like try_module_get() in device_initialize() or module_put() after calling dev->release().
Alan Stern
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |