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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
