[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1403262344060.7710@ionos.tec.linutronix.de>
Date: Wed, 26 Mar 2014 23:56:04 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Eric Dumazet <eric.dumazet@...il.com>
cc: Julia Lawall <Julia.Lawall@...6.fr>,
"David S. Miller" <davem@...emloft.net>,
kernel-janitors@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] atm: replace del_timer by del_timer_sync
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists