lkml.org 
[lkml]   [2005]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    Subject[2/3] [NEIGH] Fix add_timer race in neigh_add_timer
    From
    [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>
    --
    Visit Openswan at http://www.openswan.org/
    Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
    Home Page: http://gondor.apana.org.au/~herbert/
    PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
    diff --git a/net/core/neighbour.c b/net/core/neighbour.c
    --- a/net/core/neighbour.c
    +++ b/net/core/neighbour.c
    @@ -816,10 +816,10 @@ static void neigh_timer_handler(unsigned
    }

    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);
    \
     
     \ /
      Last update: 2005-10-23 09:34    [W:0.024 / U:93.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site