Re: SET_MODULE_OWNER

[Duncan Sands <baldrick@wanadoo.fr>]

On Friday 18 July 2003 11:05, Martin Diehl wrote:
> 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).

OK, maybe most was exagerated. :) 

If you want to see what I have in mind, do
	rmmod uhci-hcd
(or whatever your hcd is).  This shows that there was already a problem with
unloading modules with zero refcount.

> 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.

Duncan.