Skip to content

Commit

Permalink
[NEIGH] Fix add_timer race in neigh_add_timer
Browse files Browse the repository at this point in the history
neigh_add_timer cannot use add_timer unconditionally.  The reason is that
by the time it has obtained the write lock someone else (e.g., neigh_update)
could have already added a new timer.

So it should only use mod_timer and deal with its return value accordingly.

This bug would have led to rare neighbour cache entry leaks.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
  • Loading branch information
Herbert Xu committed Oct 23, 2005
1 parent 2037550 commit 6fb9974
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions net/core/neighbour.c
Original file line number Diff line number Diff line change
Expand Up @@ -816,10 +816,10 @@ static void neigh_timer_handler(unsigned long arg)
}

if (neigh->nud_state & NUD_IN_TIMER) {
neigh_hold(neigh);
if (time_before(next, jiffies + HZ/2))
next = jiffies + HZ/2;
neigh_add_timer(neigh, next);
if (!mod_timer(&neigh->timer, next))
neigh_hold(neigh);
}
if (neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) {
struct sk_buff *skb = skb_peek(&neigh->arp_queue);
Expand Down

0 comments on commit 6fb9974

Please sign in to comment.