1. 23 Oct, 2005 4 commits
    • Herbert Xu's avatar
      [NEIGH] Fix timer leak in neigh_changeaddr · 49636bb1
      Herbert Xu authored
      
      
      neigh_changeaddr attempts to delete neighbour timers without setting
      nud_state.  This doesn't work because the timer may have already fired
      when we acquire the write lock in neigh_changeaddr.  The result is that
      the timer may keep firing for quite a while until the entry reaches
      NEIGH_FAILED.
      
      It should be setting the nud_state straight away so that if the timer
      has already fired it can simply exit once we relinquish the lock.
      
      In fact, this whole function is simply duplicating the logic in
      neigh_ifdown which in turn is already doing the right thing when
      it comes to deleting timers and setting nud_state.
      
      So all we have to do is take that code out and put it into a common
      function and make both neigh_changeaddr and neigh_ifdown call it.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      49636bb1
    • Herbert Xu's avatar
      [NEIGH] Fix add_timer race in neigh_add_timer · 6fb9974f
      Herbert Xu authored
      
      
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      6fb9974f
    • Herbert Xu's avatar
      [NEIGH] Print stack trace in neigh_add_timer · 20375502
      Herbert Xu authored
      
      
      Stack traces are very helpful in determining the exact nature of a bug.
      So let's print a stack trace when the timer is added twice.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      20375502
    • Ivan Kokshaysky's avatar
      [PATCH] alpha: additional smp barriers · d475f3f4
      Ivan Kokshaysky authored
      
      
      As stated in Documentation/atomic_ops.txt, atomic functions
      returning values must have the memory barriers both before and after
      the operation.
      
      Thanks to DaveM for pointing that out.
      Signed-off-by: default avatarIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d475f3f4
  2. 22 Oct, 2005 3 commits
  3. 21 Oct, 2005 11 commits
  4. 20 Oct, 2005 22 commits