[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1407394542.11943.21.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Thu, 07 Aug 2014 08:55:42 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Deepak <deepak_das@...tor.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] net: Replace del_timer() with del_timer_sync()
On Thu, 2014-08-07 at 11:48 +0530, Deepak wrote:
> on SMP system, del_timer() might return even if the timer function
> is running on other cpu so sk_stop_timer() will execute __sock_put()
> while timer is accessing the socket on other cpu causing
> "use-after-free".
>
> This commit replaces del_timer() with del_timer_sync() in
> sk_stop_timer().
> del_timer_sync() will wait untill the timer function is not running in
> any other cpu hence making sk_stop_timer() SMP safe.
>
> Signed-off-by: Deepak Das <deepak_das@...tor.com>
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 026e01f..491a84d 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2304,7 +2304,7 @@ EXPORT_SYMBOL(sk_reset_timer);
>
> void sk_stop_timer(struct sock *sk, struct timer_list* timer)
> {
> - if (del_timer(timer))
> + if (del_timer_sync(timer))
> __sock_put(sk);
> }
> EXPORT_SYMBOL(sk_stop_timer);
There is a reason del_timer() and del_timer_sync() both exist, and both
are SMP safe.
Here, caller might block timer handler from making progress, you are
adding a deadlock condition.
In this case, there is no reason to use del_timer_sync(), you didn't
explain why you want this to happen in the first place.
If you hit a bug somewhere, please share it so that we can root cause
it.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists