Hello!
> > In 2.2 moral equivalent of del_timer_sync() is:
> >
> > start_bh_atomic();
> > del_timer();
> > end_bh_atomic();
>
> Yes, except start_bh_atomic() returns immediately if called from BH or
In 2.2 it is exactly, that we need.
> IRQ context.
Even not discussed. 8)
> One thing which we must avoid is spinning on completion of ALL BH's.
In 2.3 it is simply impossible to wait on this.
In 2.2 it is normal.
> So to synchronise we need to spin on something which is specific to
> timers. Ideally, something which is specific to the single timer in
> which we are interested. That's what my proposed patch does.
To be honest I still did not find the patch, where new del_timer()
is defined. 8)
> Yes. But not bridge, netrom, decnet, ...
Brigde and decnet must be clean as well. If they are not,
this code has active maintainers, which can be kicked.
> inet6_ifa_finish_destroy() does a del_timer() and then kfree's 'ifp'.
All these things use reference counting. When destructor is entered,
it is the last user and no timer is running on the object.
del_timer() there is pure debugging check.
> In reassembly.c, both calls to del_timer() are followed by a
> frag_kfree_s(fq), but the handler could still be running, and it
> accesses *fq.
Yes... It was safe in 2.2 (BH only), now it is bug. And del_timer_sync()
is dangerous to be used here, reassembly function could be called
from an obscure context... Reference counting.
> BTW: I prefer the name "del_timer_async" - it makes people THINK before
> using it. I'd like to rename del_timer_sync to del_timer_can_deadlock
> as well :)
I agreed! The thing, which I still do not understand is how you managed
to implement correct del_timer_sync(). 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:17 EST