Re: SET_MODULE_OWNER

[Martin Diehl <lists@mdiehl.de>]

On Fri, 18 Jul 2003, Duncan Sands wrote:

> On Thursday 17 July 2003 22:22, Jeff Garzik wrote:
> > David S. Miller wrote:
> > > On Thu, 17 Jul 2003 12:00:58 -0400
> > >
> > > Jeff Garzik <jgarzik@pobox.com> wrote:
> > >>David?  Does Rusty have a plan here or something?
> > >
> > > It just works how it works and that's it.
> > >
> > > Net devices are reference counted, anything more is superfluous.
> > > They may be yanked out of the kernel whenever you want.
> >
> > (I'm obviously just realizing the implications of this... missed it
> > completely during the earlier discussions)
> >
> > Object lifetime is just part of the story.
> >
> > This change is a major behavior change.  The whole point of removing a
> > module is knowing its gone ;-)  And that is completely changed now.
> > Modules are very often used by developers in a "modprobe ; test ; rmmod"
> > cycle, and that's now impossible (you don't know when the net device,
> > and thus your code, is really gone).  It's already breaking userland,
> > which does sweeps for zero-refcount modules among other things.
> 
> Most USB drivers can be unloaded at any time, so this problem already
> existed elsewhere.

Most? Since when?

For me neither usb-storage nor usbserial (pl2303 f.e.) can be unloaded 
when in use (storage being mounted or /dev/usb/ttyUSBX opened).

True, irda-usb (and probably usbnet) can be unloaded when the interface is 
up since a few weeks - but this is due to the networking not bumping 
the module use counter anymore, nothing todo with usb.

Doing something comparable to network with usb in general one would need 
to change usb-storage reporting use-count==0 while the disk is mounted!
Only then one could rmmod and the fs would (hopefully) get synced and 
unmounted (or staled) automagically.

Personally I believe it all comes down to the semantics of the module use 
counter. If it's taken to indicate the module cannot be unloaded while 
!=0, it might (or should) stay ==0 if the underlaying subsystem can handle 
module removal at any time safe - like it is done for network now.

In contrast, if the module use count is taken to indicate a module is in 
use (interface up, fs mounted, chardev open, ...) I'd expect it to be >0.
Being unable to rmmod in this situation is just a consequence of the fact 
it's being used then, regardless whether we could rmmod anyway.

OTOH David has a point as the current situation with network helps to 
identify bugs there - YMMV.

Martin