1. 10 3月, 2009 1 次提交
  2. 01 2月, 2009 1 次提交
  3. 17 11月, 2008 1 次提交
    • B
      ipv4: Fix ARP behavior with many mac-vlans · 8164f1b7
      Ben Greear 提交于
      Ben Greear wrote:
      > I have 500 mac-vlans on a system talking to 500 other
      > mac-vlans.  My problem is that the arp-table gets extremely
      > huge because every time an arp-request comes in on all mac-vlans,
      > a stale arp entry is added for each mac-vlan.  I have filtering
      > turned on, but that doesn't help because the neigh_event_ns call
      > below will cause a stale neighbor entry to be created regardless
      > of whether a replay will be sent or not.
      > Maybe the neigh_event code should be below the checks for dont_send,
      > and only create check neigh_event_ns if we are !dont_send?
      
      The attached patch makes it work much better for me.  The patch
      will cause the code to NOT create a stale neighbor entry if we
      are not going to respond to the ARP request.  The old code
      *would* create a stale entry even if we are not going to respond.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8164f1b7
  4. 03 11月, 2008 1 次提交
  5. 31 10月, 2008 1 次提交
  6. 20 10月, 2008 1 次提交
  7. 17 7月, 2008 2 次提交
  8. 06 7月, 2008 1 次提交
  9. 12 6月, 2008 1 次提交
  10. 22 5月, 2008 1 次提交
  11. 13 5月, 2008 1 次提交
  12. 14 4月, 2008 1 次提交
  13. 26 3月, 2008 1 次提交
  14. 25 3月, 2008 2 次提交
  15. 06 3月, 2008 1 次提交
  16. 04 3月, 2008 1 次提交
  17. 18 2月, 2008 1 次提交
  18. 13 2月, 2008 1 次提交
    • D
      [NDISC]: Fix race in generic address resolution · 69cc64d8
      David S. Miller 提交于
      Frank Blaschka provided the bug report and the initial suggested fix
      for this bug.  He also validated this version of this fix.
      
      The problem is that the access to neigh->arp_queue is inconsistent, we
      grab references when dropping the lock lock to call
      neigh->ops->solicit() but this does not prevent other threads of
      control from trying to send out that packet at the same time causing
      corruptions because both code paths believe they have exclusive access
      to the skb.
      
      The best option seems to be to hold the write lock on neigh->lock
      during the ->solicit() call.  I looked at all of the ndisc_ops
      implementations and this seems workable.  The only case that needs
      special care is the IPV4 ARP implementation of arp_solicit().  It
      wants to take neigh->lock as a reader to protect the header entry in
      neigh->ha during the emission of the soliciation.  We can simply
      remove the read lock calls to take care of that since holding the lock
      as a writer at the caller providers a superset of the protection
      afforded by the existing read locking.
      
      The rest of the ->solicit() implementations don't care whether the
      neigh is locked or not.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69cc64d8
  19. 01 2月, 2008 1 次提交
  20. 29 1月, 2008 14 次提交
  21. 26 1月, 2008 1 次提交
    • R
      IPoIB: improve IPv4/IPv6 to IB mcast mapping functions · a9e527e3
      Rolf Manderscheid 提交于
      An IPoIB subnet on an IB fabric that spans multiple IB subnets can't
      use link-local scope in multicast GIDs.  The existing routines that
      map IP/IPv6 multicast addresses into IB link-level addresses hard-code
      the scope to link-local, and they also leave the partition key field
      uninitialised.  This patch adds a parameter (the link-level broadcast
      address) to the mapping routines, allowing them to initialise both the
      scope and the P_Key appropriately, and fixes up the call sites.
      
      The next step will be to add a way to configure the scope for an IPoIB
      interface.
      Signed-off-by: NRolf Manderscheid <rvm@obsidianresearch.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      a9e527e3
  22. 20 12月, 2007 1 次提交
  23. 26 11月, 2007 1 次提交
  24. 21 11月, 2007 1 次提交
  25. 11 10月, 2007 1 次提交