1. 23 10月, 2005 3 次提交
    • H
      [NEIGH] Fix timer leak in neigh_changeaddr · 49636bb1
      Herbert Xu 提交于
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      49636bb1
    • H
      [NEIGH] Fix add_timer race in neigh_add_timer · 6fb9974f
      Herbert Xu 提交于
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      6fb9974f
    • H
      [NEIGH] Print stack trace in neigh_add_timer · 20375502
      Herbert Xu 提交于
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      20375502
  2. 28 9月, 2005 1 次提交
  3. 25 9月, 2005 1 次提交
  4. 30 8月, 2005 2 次提交
  5. 29 6月, 2005 1 次提交
  6. 24 6月, 2005 1 次提交
  7. 19 6月, 2005 5 次提交
  8. 29 4月, 2005 1 次提交
  9. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4