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

\
 
 \ /
  Last update: 2007-04-16 21:57    [W:0.036 / U:1.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site