>
>
> On Wed, 26 Aug 1998, Alan Cox wrote:
> >
> > Also that bug has been there for a lot longer than the past 2 or 3 kernels
>
> This is btw not necessarily true..
>
> del_timer() doing a synchronize_bh() is actually a fairly new thing: it's
> definitely the "right thing" TM to do (the comment says exactly why: we
> shouldn't return from del_timer until we've made sure that the timer has
> really gone away), but it may not be the right place to do this all.
>
I don't see how this could the "right thing"? del_timer only removes the
timer from the timer list that run_timer_list traverses to run timer
handlers, and there shouldn't be any races in the two functions.
I tried to make add_timer/del_timer/mod_timer callable from any context,
including the timer handler for the timer itself. Wouldn't del_timer
deadlock if it was called from a timer handler with the synchronize_bh in?
(I may have misread the synchronize_bh function).
del_timer does
spin_lock_irqsave(&timerlist_lock, flags);
ret = detach_timer(timer);
timer->next = timer->prev = 0;
spin_unlock_irqrestore(&timerlist_lock, flags);
and the inner loop of run_timer_list does
void (*fn)(unsigned long) = timer->function;
unsigned long data = timer->data;
detach_timer(timer);
timer->next = timer->prev = NULL;
spin_unlock_irq(&timerlist_lock);
fn(data);
spin_lock_irq(&timerlist_lock);
So by the time the timer function is run, the timer is no longer in use,
and a call to del_timer while the timer handling function is running will
have zero effect.
- Finn Arne
-
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.altern.org/andrebalsa/doc/lkml-faq.html