On Wed, 26 Mar 2014, Eric Dumazet wrote: > On Wed, 2014-03-26 at 23:02 +0100, Thomas Gleixner wrote: > > > That's why you need del_timer_sync() it waits for the timer handler to > > complete and then removes it. > > Interesting... So maybe some comment is stale ? > > > diff --git a/kernel/timer.c b/kernel/timer.c > index accfd241b9e5..c948fa2fc065 100644 > --- a/kernel/timer.c > +++ b/kernel/timer.c > @@ -1011,10 +1011,10 @@ EXPORT_SYMBOL(try_to_del_timer_sync); > * the timer it also makes sure the handler has finished executing on other > * CPUs. > * > - * Synchronization rules: Callers must prevent restarting of the timer, > - * otherwise this function is meaningless. It must not be called from We still need to prevent restarting from some other site, i.e. interrupt. It's fine if the timer handler itself restarts the timer, as del_timer_sync() wait for the handler to finish and then delete the timer. I can't find the reason why it can't call add_timer_on(). We lock/unlock the timer base in every try_to_del_timer_sync() loop so we detect the base change. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html