[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1439501412.7960.22.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Thu, 13 Aug 2015 14:30:12 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net] inet: fix races with reqsk timers
On Fri, 2015-08-14 at 00:13 +0300, Nikolay Aleksandrov wrote:
> > On Aug 13, 2015, at 11:44 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> >
> > On Thu, 2015-08-13 at 13:19 -0700, Eric Dumazet wrote:
> >
> >>
> >> A caller handler can not call del_timer_sync()
> >
> > A timer handler can not call del_timer_sync()
> >
> > I am testing a minimal fix :
> >
> > diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> > index 05e3145f7dc3..134957159c27 100644
> > --- a/net/ipv4/inet_connection_sock.c
> > +++ b/net/ipv4/inet_connection_sock.c
> > @@ -593,7 +593,7 @@ static bool reqsk_queue_unlink(struct request_sock_queue *queue,
> > }
> >
> > spin_unlock(&queue->syn_wait_lock);
> > - if (del_timer_sync(&req->rsk_timer))
> > + if (timer_pending(&req->rsk_timer) && del_timer_sync(&req->rsk_timer))
> > reqsk_put(req);
> > return found;
> > }
> >
> >
>
> Wouldn’t try_to_del_timer_sync(&req->rsk_timer) > 0 be better ?
I am not sure : there are contexts where we need to wait for the timer
being completed (this was point of commit
2235f2ac75fd2501c251b0b699a9632e80239a6d)
(problem is that timer handler can rearm itself)
--
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