Re: [Patch -mm 3/3] RFC: Introduce kobject->owner for refcounting.

[Alan Stern <stern@rowland.harvard.edu>]

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/