Re: [patches] kernel timer races

Date: Sat May 27 2000 - 12:06:44 EST


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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:17 EST