Re: owner field in `struct fs'

[Andrew Morton]

Rusty Russell wrote:
> 
> In message <[e-mail]-net> you write:
> > On Mon, 26 Jun 2000 02:25:13 +1000,
> > Rusty Russell <[e-mail]> wrote:
> > >However, my request for sane module semantics remains for other
> > >subsystems.  There are other problems[1], but this addresses an important
> > >one.
> > >[1]  We also need to sync against timers before freeing the module memory.
> >
> > Is this problem not a subset of the existing timer cleanup?  Timers and
> > modules are only a problem if the module cleanup code exits to
> > delete_module() while the timer is still running.  I understood that
> > Andrew Morton's work would force timer deletion to wait until the timer
> > had been fully deleted.
> 
> AFAIK his work never went in/was never completed 8( So del_timer_sync
> doesn't work on self-deleting timers.

His work was a masterpiece.  Linus was looking at the timer_exit()
abomination last week and I sent a smorgasbord of patches which remove
it.  Hoping to see one come back at us soon.

But del_timer_sync(), like del_timer() still must not be used on
self-kfreeing timers.  I think a variant could be made to do so quite
easily (esp. if Linus chooses the right patch).

- grab the timerlist_lock
- see if any timers are running.  If so, unlock and retry.
- walk the tvecs looking for the timer.

Very expensive but OK for occasional things like module unload.

The refcounting games which you and Alexey play are more efficient,
elegant and general, but hard for mortals to employ.   Particularly if
the timer is to be grafted onto some existing subsystem.