Re: [patches] kernel timer races

From: Andrew Morton (
Date: Thu May 25 2000 - 10:02:37 EST

Alan Cox wrote:
> > More hmm... synchronize_bh() doesn't do anything to stop a new BH from
> > starting as soon as it has returned. So it's safe within __global_cli()
> > and it can be used after del_timer() to give del_timer_sync() semantics,
> > but apart from that, what use is it??
> Im thinking
> del_timer();
> del_timer();
> blah
> wait_timers();

Yes, that will work in process context but can't be globally macro'ed or
inlined onto the original del_timer because extra checking is needed in
BH/IRQ context.

IMO, all ~700 uses of del_timer() should use the synchronous version
until they have been audited for del_timer_async()-safety.

> Which happens to avoid the overhead and cost in the normal timer deletion
> path.

The cost isn't too high, actually. A memory read in internal_add_timer,
a read and a write in del_timer and four writes in run_timer_list().
Much more cost if the special-case code is triggered, of course. Very

> > BTW2: is there any technical reason why the timer_struct clients haven't
> > been migrated over to use timer_list yet?
> Not that I know of



- 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:14 EST