1. 09 12月, 2006 1 次提交
  2. 08 12月, 2006 1 次提交
  3. 03 12月, 2006 2 次提交
  4. 04 10月, 2006 1 次提交
  5. 29 9月, 2006 1 次提交
  6. 23 9月, 2006 10 次提交
  7. 18 9月, 2006 1 次提交
  8. 03 8月, 2006 1 次提交
  9. 01 7月, 2006 1 次提交
  10. 13 5月, 2006 1 次提交
    • S
      [NEIGH]: Fix IP-over-ATM and ARP interaction. · bd89efc5
      Simon Kelley 提交于
      The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
      ARP table, using the standard neighbour-table code. The
      neigh_table_init function adds this neighbour table to a linked list
      of all neighbor tables which is used by the functions neigh_delete()
      neigh_add() and neightbl_set(), all called by the netlink code.
      
      Once the ATM neighbour table is added to the list, there are two
      tables with family == AF_INET there, and ARP entries sent via netlink
      go into the first table with matching family. This is indeterminate
      and often wrong.
      
      To see the bug, on a kernel with CLIP enabled, create a standard IPv4
      ARP entry by pinging an unused address on a local subnet. Then attempt
      to complete that entry by doing
      
      ip neigh replace <ip address> lladdr <some mac address> nud reachable
      
      Looking at the ARP tables by using 
      
      ip neigh show
      
      will reveal two ARP entries for the same address. One of these can be
      found in /proc/net/arp, and the other in /proc/net/atm/arp.
      
      This patch adds a new function, neigh_table_init_no_netlink() which
      does everything the neigh_table_init() does, except add the table to
      the netlink all-arp-tables chain. In addition neigh_table_init() has a
      check that all tables on the chain have a distinct address family.
      The init call in clip.c is changed to call
      neigh_table_init_no_netlink().
      
      Since ATM ARP tables are rather more complicated than can currently be
      handled by the available rtattrs in the netlink protocol, no
      functionality is lost by this patch, and non-ATM ARP manipulation via
      netlink is rescued. A more complete solution would involve a rtattr
      for ATM ARP entries and some way for the netlink code to give
      neigh_add and friends more information than just address family with
      which to find the correct ARP table.
      
      [ I've changed the assertion checking in neigh_table_init() to not
        use BUG_ON() while holding neigh_tbl_lock.  Instead we remember that
        we found an existing tbl with the same family, and after dropping
        the lock we'll give a diagnostic kernel log message and a stack dump.
        -DaveM ]
      Signed-off-by: NSimon Kelley <simon@thekelleys.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd89efc5
  11. 11 4月, 2006 1 次提交
  12. 10 4月, 2006 1 次提交
  13. 21 3月, 2006 2 次提交
  14. 26 10月, 2005 1 次提交
  15. 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
  16. 28 9月, 2005 1 次提交
  17. 25 9月, 2005 1 次提交
  18. 30 8月, 2005 2 次提交
  19. 29 6月, 2005 1 次提交
  20. 24 6月, 2005 1 次提交
  21. 19 6月, 2005 5 次提交
  22. 29 4月, 2005 1 次提交