From: Eric Dumazet
> Sent: 18 August 2015 14:37
> On Tue, 2015-08-18 at 11:04 +0000, David Laight wrote:
> > From: Eric Dumazet
> > > Sent: 13 August 2015 23:45
> > > When replacing del_timer() with del_timer_sync(), I introduced
> > > a deadlock condition :
> > >
> > > reqsk_queue_unlink() is called from inet_csk_reqsk_queue_drop()
> > >
> > > inet_csk_reqsk_queue_drop() can be called from many contexts,
> > > one being the timer handler itself (reqsk_timer_handler()).
> > >
> > > In this case, del_timer_sync() loops forever.
> > >
> > > Simple fix is to test if timer is pending.
> >
> > Doesn't that mean you fail to wait for the timer function
> > to finish if you are calling from a different context?
>
> No, this is the purpose of del_timer_sync()
I wasn't worried about del_timer_sync().
The problem is the call to timer_pending().
If the timer has just expired, and the timeout function is running
(on another cpu) then timer_pending() will return false.
So any tidyup path (apart from that called by the timeout function itself)
will fail to wait for the function to finish.
So, in effect, you've converted the code back into a call to del_timer().
timer_pending() should probably never be called without the relevant
timer lock help - because the result is stale.
David
