Re: Unregistering interfaces

[Greg KH]

On Mon, Mar 29, 2004 at 01:25:51PM -0800, Andrew Morton wrote:
> Greg KH <greg@xxxxxxxxx> wrote:
> >
> > On Sun, Mar 28, 2004 at 12:38:57PM -0800, Andrew Morton wrote:
> > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > >  However, a very noticeable and IMO unacceptable delay occurs when there's
> > > >  a reference to a kobject caused by a negative dentry that won't get
> > > >  recycled until the system decides it's good and ready.  That's the real
> > > >  problem I wanted to call to people's attention.
> > > 
> > > Have you verified that this actually happens?
> > 
> > Yes, I've verified this, and it looks like Maneesh also agrees with
> > this.
> > 
> > > If so, what are its effects?  rmmod hangs for half an hour?  Cannot reload
> > > the module?
> > 
> > Well, before the patch that I submitted for the USB core, we would hang
> > waiting for the release function to return as there was still a
> > reference to the kobject pending.
> > 
> > For other subsystems (and USB), this might cause nasty oopses when the
> > kobject is finally released and yet the module has been unloaded already
> > (as the owner of the reference did not cause the module reference count
> > to increment.)  This is bad.
> > 
> 
> 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.

> But the module system is that smart, so what we do instead is to block
> rmmod until the module refcount falls to zero, and rmmod then does the
> final destruction.  We could have punted the module destruction up to some
> reaper thread but for some reason did not do so.

Well, as the module refcount was never incremented, it does not do this.
I just verified this (accidentally) by removing my lp modules and then
doing a bk pull.  kswapd forced the stale dentry out, which decremented
the kobject reference count, which then tried to call the release
function in the (now gone) lp module.  My machine then spit up a lovely
oops, and was reduced to a unusable sludge as there was no more kswapd
running :(

> So as far as I can tell, the only problem we have is that rmmod will hang
> around until memory pressure, yes?

Nope, oopses will happen.  You can verify this yourself by doing much of
what I just did.

This needs to get fixed, as it's not just a USB issue (so I've added
lkml on the cc list.)

> Maybe a shrink_dcache_parent(dentry) on entry to simple_rmdir() would
> suffice?

Will that get rid of the references properly nwhen we remove the
kobject?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/