Re: Unregistering interfaces

Alan Stern
2004-03-30T15:40:02Z

On Mon, 29 Mar 2004, Greg KH wrote:

> On Mon, Mar 29, 2004 at 03:31:17PM -0800, Andrew Morton wrote:
> > Greg KH <greg@kroah.com> wrote:
> > >
> > > > The module should remain in memory, "unhashed", until the final kobject
> > > > reference falls to zero. Destruction of that kobject causes the refcount
> > > > on the module to fall to zero which causes the entire module to be
> > > > released.
> > > >
> > > > (hmm, the existence of a kobject doesn't appear to contribute to its
> > > > module's refcount. Why not?)
> > >
> > > It does, if a file for that kobject is opened. In this case, there was
> > > no file opened, so the module refcount isn't incremented.
> >
> > hm, surprised. Shouldn't the existence of a kobject contribute to its
> > module's refcount?
>
> No, a kobject by itself knows nothing about a module. Only the
> attribute files do (and they are the things that contain the struct
> module *), as they are what user space can grab references to.

There's another reason. Practically every module has kobjects registered
all the time; they are not unregistered until the module's unload
procedure runs. If these kobjects contributed to the modules refcount
then it would be impossible ever to rmmod the module without using the -f
flag.

Furthermore, all the excess usage counts from those kobjects would swamp
and hide the genuine usage counts (the ones that are displayed now). The
user would have no way to know whether rmmod -f would work or would hang.

Alan Stern