1. 03 8月, 2009 1 次提交
    • E
      neigh: Convert garbage collection from softirq to workqueue · e4c4e448
      Eric Dumazet 提交于
      Current neigh_periodic_timer() function is fired by timer IRQ, and
      scans one hash bucket each round (very litle work in fact)
      
      As we are supposed to scan whole hash table in 15 seconds, this means
      neigh_periodic_timer() can be fired very often. (depending on the number
      of concurrent hash entries we stored in this table)
      
      Converting this to a workqueue permits scanning whole table, minimizing
      icache pollution, and firing this work every 15 seconds, independantly
      of hash table size.
      
      This 15 seconds delay is not a hard number, as work is a deferrable one.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4c4e448
  2. 12 11月, 2008 2 次提交
  3. 17 7月, 2008 1 次提交
    • N
      core: add stat to track unresolved discards in neighbor cache · 9a6d276e
      Neil Horman 提交于
      in __neigh_event_send, if we have a neighbour entry which is in
      NUD_INCOMPLETE state, we enqueue any outbound frames to that neighbour
      to the neighbours arp_queue, which is default capped to a length of 3
      skbs.  If that queue exceeds its set length, it will drop an skb on
      the queue to enqueue the newly arrived skb.  This results in a drop
      for which we have no statistics incremented.  This patch adds an
      unresolved_discards stat to /proc/net/stat/ndisc_cache to track these
      lost frames.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a6d276e
  4. 26 3月, 2008 1 次提交
  5. 25 3月, 2008 1 次提交
    • P
      [NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns (v3). · fa86d322
      Pavel Emelyanov 提交于
      Proxy neighbors do not have any reference counting, so any caller
      of pneigh_lookup (unless it's a netlink triggered add/del routine)
      should _not_ perform any actions on the found proxy entry. 
      
      There's one exception from this rule - the ipv6's ndisc_recv_ns() 
      uses found entry to check the flags for NTF_ROUTER.
      
      This creates a race between the ndisc and pneigh_delete - after 
      the pneigh is returned to the caller, the nd_tbl.lock is dropped 
      and the deleting procedure may proceed.
      
      One of the fixes would be to add a reference counting, but this
      problem exists for ndisc only. Besides such a patch would be too 
      big for -rc4.
      
      So I propose to introduce a __pneigh_lookup() which is supposed
      to be called with the lock held and use it in ndisc code to check
      the flags on alive pneigh entry.
      
      
      Changes from v2:
      As David noticed, Exported the __pneigh_lookup() to ipv6 module. 
      The checkpatch generates a warning on it, since the EXPORT_SYMBOL 
      does not follow the symbol itself, but in this file all the 
      exports come at the end, so I decided no to break this harmony.
      
      Changes from v1:
      Fixed comments from YOSHIFUJI - indentation of prototype in header
      and the pndisc_check_router() name - and a compilation fix, pointed
      by Daniel - the is_routed was (falsely) considered as uninitialized
      by gcc.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa86d322
  6. 04 3月, 2008 1 次提交
  7. 29 1月, 2008 5 次提交
  8. 26 4月, 2007 1 次提交
  9. 26 3月, 2007 1 次提交
    • A
      [NET]: Fix neighbour destructor handling. · ecbb4169
      Alexey Kuznetsov 提交于
      ->neigh_destructor() is killed (not used), replaced with
      ->neigh_cleanup(), which is called when neighbor entry goes to dead
      state. At this point everything is still valid: neigh->dev,
      neigh->parms etc.
      
      The device should guarantee that dead neighbor entries (neigh->dead !=
      0) do not get private part initialized, otherwise nobody will cleanup
      it.
      
      I think this is enough for ipoib which is the only user of this thing.
      Initialization private part of neighbor entries happens in ipib
      start_xmit routine, which is not reached when device is down.  But it
      would be better to add explicit test for neigh->dead in any case.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ecbb4169
  10. 09 12月, 2006 1 次提交
  11. 08 12月, 2006 1 次提交
  12. 23 9月, 2006 3 次提交
  13. 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
  14. 21 3月, 2006 1 次提交
    • M
      [NET]: Move destructor from neigh->ops to neigh_params · c5ecd62c
      Michael S. Tsirkin 提交于
      struct neigh_ops currently has a destructor field, which no in-kernel
      drivers outside of infiniband use.  The infiniband/ulp/ipoib in-tree
      driver stashes some info in the neighbour structure (the results of
      the second-stage lookup from ARP results to real link-level path), and
      it uses neigh->ops->destructor to get a callback so it can clean up
      this extra info when a neighbour is freed.  We've run into problems
      with this: since the destructor is in an ops field that is shared
      between neighbours that may belong to different net devices, there's
      no way to set/clear it safely.
      
      The following patch moves this field to neigh_parms where it can be
      safely set, together with its twin neigh_setup.  Two additional
      patches in the patch series update ipoib to use this new interface.
      Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5ecd62c
  15. 04 1月, 2006 1 次提交
  16. 30 8月, 2005 1 次提交
  17. 19 6月, 2005 2 次提交
    • T
    • T
      [NETLINK]: Neighbour table configuration and statistics via rtnetlink · c7fb64db
      Thomas Graf 提交于
      To retrieve the neighbour tables send RTM_GETNEIGHTBL with the
      NLM_F_DUMP flag set. Every neighbour table configuration is
      spread over multiple messages to avoid running into message
      size limits on systems with many interfaces. The first message
      in the sequence transports all not device specific data such as
      statistics, configuration, and the default parameter set.
      This message is followed by 0..n messages carrying device
      specific parameter sets.
      
      Although the ordering should be sufficient, NDTA_NAME can be
      used to identify sequences. The initial message can be identified
      by checking for NDTA_CONFIG. The device specific messages do
      not contain this TLV but have NDTPA_IFINDEX set to the
      corresponding interface index.
      
      To change neighbour table attributes, send RTM_SETNEIGHTBL
      with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3],
      NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked
      otherwise. Device specific parameter sets can be changed by
      setting NDTPA_IFINDEX to the interface index of the corresponding
      device.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7fb64db
  18. 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