[NEIGH] Fix add_timer race in neigh_add_timer
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>
This commit is contained in:
parent
203755029e
commit
6fb9974f49
|
@ -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);
|
||||
|
|
Loading…
Reference in New Issue