1. 05 6月, 2017 1 次提交
    • S
      neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d" · 5071034e
      Sowmini Varadhan 提交于
      The command
        # arp -s 62.2.0.1 a:b:c:d:e:f dev eth2
      adds an entry like the following (listed by "arp -an")
        ? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2
      but the symmetric deletion command
        # arp -i eth2 -d 62.2.0.1
      does not remove the PERM entry from the table, and instead leaves behind
        ? (62.2.0.1) at <incomplete> on eth2
      
      The reason is that there is a refcnt of 1 for the arp_tbl itself
      (neigh_alloc starts off the entry with a refcnt of 1), thus
      the neigh_release() call from arp_invalidate() will (at best) just
      decrement the ref to 1, but will never actually free it from the
      table.
      
      To fix this, we need to do something like neigh_forced_gc: if
      the refcnt is 1 (i.e., on the table's ref), remove the entry from
      the table and free it. This patch refactors and shares common code
      between neigh_forced_gc and the newly added neigh_remove_one.
      
      A similar issue exists for IPv6 Neighbor Cache entries, and is fixed
      in a similar manner by this patch.
      Signed-off-by: NSowmini Varadhan <sowmini.varadhan@oracle.com>
      Reviewed-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5071034e
  2. 13 4月, 2017 1 次提交
  3. 23 3月, 2017 1 次提交
  4. 12 2月, 2017 1 次提交
  5. 11 8月, 2015 1 次提交
    • R
      net: add explicit logging and stat for neighbour table overflow · fb811395
      Rick Jones 提交于
      Add an explicit neighbour table overflow message (ratelimited) and
      statistic to make diagnosing neighbour table overflows tractable in
      the wild.
      
      Diagnosing a neighbour table overflow can be quite difficult in the wild
      because there is no explicit dmesg logged.  Callers to neighbour code
      seem to use net_dbg_ratelimit when the neighbour call fails which means
      the "base message" is not emitted and the callback suppressed messages
      from the ratelimiting can end-up juxtaposed with unrelated messages.
      Further, a forced garbage collection will increment a stat on each call
      whether it was successful in freeing-up a table entry or not, so that
      statistic is only a hint.  So, add a net_info_ratelimited message and
      explicit statistic to the neighbour code.
      Signed-off-by: NRick Jones <rick.jones2@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb811395
  6. 21 3月, 2015 1 次提交
  7. 13 3月, 2015 1 次提交
    • E
      net: Introduce possible_net_t · 0c5c9fb5
      Eric W. Biederman 提交于
      Having to say
      > #ifdef CONFIG_NET_NS
      > 	struct net *net;
      > #endif
      
      in structures is a little bit wordy and a little bit error prone.
      
      Instead it is possible to say:
      > typedef struct {
      > #ifdef CONFIG_NET_NS
      >       struct net *net;
      > #endif
      > } possible_net_t;
      
      And then in a header say:
      
      > 	possible_net_t net;
      
      Which is cleaner and easier to use and easier to test, as the
      possible_net_t is always there no matter what the compile options.
      
      Further this allows read_pnet and write_pnet to be functions in all
      cases which is better at catching typos.
      
      This change adds possible_net_t, updates the definitions of read_pnet
      and write_pnet, updates optional struct net * variables that
      write_pnet uses on to have the type possible_net_t, and finally fixes
      up the b0rked users of read_pnet and write_pnet.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c5c9fb5
  8. 09 3月, 2015 1 次提交
  9. 04 3月, 2015 2 次提交
    • E
      neigh: Add helper function neigh_xmit · 4fd3d7d9
      Eric W. Biederman 提交于
      For MPLS I am building the code so that either the neighbour mac
      address can be specified or we can have a next hop in ipv4 or ipv6.
      
      The kind of next hop we have is indicated by the neighbour table
      pointer.  A neighbour table pointer of NULL is a link layer address.
      A non-NULL neighbour table pointer indicates which neighbour table and
      thus which address family the next hop address is in that we need to
      look up.
      
      The code either sends a packet directly or looks up the appropriate
      neighbour table entry and sends the packet.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4fd3d7d9
    • E
      neigh: Factor out ___neigh_lookup_noref · 60395a20
      Eric W. Biederman 提交于
      While looking at the mpls code I found myself writing yet another
      version of neigh_lookup_noref.  We currently have __ipv4_lookup_noref
      and __ipv6_lookup_noref.
      
      So to make my work a little easier and to make it a smidge easier to
      verify/maintain the mpls code in the future I stopped and wrote
      ___neigh_lookup_noref.  Then I rewote __ipv4_lookup_noref and
      __ipv6_lookup_noref in terms of this new function.  I tested my new
      version by verifying that the same code is generated in
      ip_finish_output2 and ip6_finish_output2 where these functions are
      inlined.
      
      To get to ___neigh_lookup_noref I added a new neighbour cache table
      function key_eq.  So that the static size of the key would be
      available.
      
      I also added __neigh_lookup_noref for people who want to to lookup
      a neighbour table entry quickly but don't know which neibhgour table
      they are going to look up.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60395a20
  10. 03 3月, 2015 2 次提交
  11. 27 12月, 2014 1 次提交
  12. 12 11月, 2014 1 次提交
  13. 30 10月, 2014 1 次提交
  14. 27 9月, 2014 1 次提交
    • P
      netfilter: bridge: move br_netfilter out of the core · 34666d46
      Pablo Neira Ayuso 提交于
      Jesper reported that br_netfilter always registers the hooks since
      this is part of the bridge core. This harms performance for people that
      don't need this.
      
      This patch modularizes br_netfilter so it can be rmmod'ed, thus,
      the hooks can be unregistered. I think the bridge netfilter should have
      been a separated module since the beginning, Patrick agreed on that.
      
      Note that this is breaking compatibility for users that expect that
      bridge netfilter is going to be available after explicitly 'modprobe
      bridge' or via automatic load through brctl.
      
      However, the damage can be easily undone by modprobing br_netfilter.
      The bridge core also spots a message to provide a clue to people that
      didn't notice that this has been deprecated.
      
      On top of that, the plan is that nftables will not rely on this software
      layer, but integrate the connection tracking into the bridge layer to
      enable stateful filtering and NAT, which is was bridge netfilter users
      seem to require.
      
      This patch still keeps the fake_dst_ops in the bridge core, since this
      is required by when the bridge port is initialized. So we can safely
      modprobe/rmmod br_netfilter anytime.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: NFlorian Westphal <fw@strlen.de>
      34666d46
  15. 15 7月, 2014 1 次提交
  16. 17 1月, 2014 1 次提交
  17. 12 12月, 2013 1 次提交
    • J
      ipv6: router reachability probing · 7e980569
      Jiri Benc 提交于
      RFC 4191 states in 3.5:
      
         When a host avoids using any non-reachable router X and instead sends
         a data packet to another router Y, and the host would have used
         router X if router X were reachable, then the host SHOULD probe each
         such router X's reachability by sending a single Neighbor
         Solicitation to that router's address.  A host MUST NOT probe a
         router's reachability in the absence of useful traffic that the host
         would have sent to the router if it were reachable.  In any case,
         these probes MUST be rate-limited to no more than one per minute per
         router.
      
      Currently, when the neighbour corresponding to a router falls into
      NUD_FAILED, it's never considered again. Introduce a new rt6_nud_state
      value, RT6_NUD_FAIL_PROBE, which suggests the route should not be used but
      should be probed with a single NS. The probe is ratelimited by the existing
      code. To better distinguish meanings of the failure values, rename
      RT6_NUD_FAIL_SOFT to RT6_NUD_FAIL_DO_RR.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e980569
  18. 10 12月, 2013 4 次提交
  19. 01 8月, 2013 1 次提交
  20. 11 2月, 2013 1 次提交
  21. 29 1月, 2013 1 次提交
    • Y
      net neigh: Optimize neighbor entry size calculation. · 08433eff
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      When allocating memory for neighbour cache entry, if
      tbl->entry_size is not set, we always calculate
      sizeof(struct neighbour) + tbl->key_len, which is common
      in the same table.
      
      With this change, set tbl->entry_size during the table
      initialization phase, if it was not set, and use it in
      neigh_alloc() and neighbour_priv().
      
      This change also allow us to have both of protocol private
      data and device priate data at tha same time.
      
      Note that the only user of prototcol private is DECnet
      and the only user of device private is ATM CLIP.
      Since those are exclusive, we have not been facing issues
      here.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08433eff
  22. 08 8月, 2012 1 次提交
    • E
      net: output path optimizations · 425f09ab
      Eric Dumazet 提交于
      1) Avoid dirtying neighbour's confirmed field.
      
        TCP workloads hits this cache line for each incoming ACK.
        Lets write n->confirmed only if there is a jiffie change.
      
      2) Optimize neigh_hh_output() for the common Ethernet case, were
         hh_len is less than 16 bytes. Replace the memcpy() call
         by two inlined 64bit load/stores on x86_64.
      
      Bench results using udpflood test, with -C option (MSG_CONFIRM flag
      added to sendto(), to reproduce the n->confirmed dirtying on UDP)
      
      24 threads doing 1.000.000 UDP sendto() on dummy device, 4 runs.
      
      before : 2.247s, 2.235s, 2.247s, 2.318s
      after  : 1.884s, 1.905s, 1.891s, 1.895s
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      425f09ab
  23. 05 7月, 2012 2 次提交
  24. 16 4月, 2012 1 次提交
  25. 14 4月, 2012 1 次提交
  26. 29 12月, 2011 1 次提交
  27. 20 12月, 2011 1 次提交
  28. 14 12月, 2011 1 次提交
  29. 01 12月, 2011 2 次提交
  30. 14 11月, 2011 1 次提交
    • E
      neigh: new unresolved queue limits · 8b5c171b
      Eric Dumazet 提交于
      Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
      > From: David Miller <davem@davemloft.net>
      > Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
      >
      > > From: Eric Dumazet <eric.dumazet@gmail.com>
      > > Date: Wed, 09 Nov 2011 12:14:09 +0100
      > >
      > >> unres_qlen is the number of frames we are able to queue per unresolved
      > >> neighbour. Its default value (3) was never changed and is responsible
      > >> for strange drops, especially if IP fragments are used, or multiple
      > >> sessions start in parallel. Even a single tcp flow can hit this limit.
      > >  ...
      > >
      > > Ok, I've applied this, let's see what happens :-)
      >
      > Early answer, build fails.
      >
      > Please test build this patch with DECNET enabled and resubmit.  The
      > decnet neigh layer still refers to the removed ->queue_len member.
      >
      > Thanks.
      
      Ouch, this was fixed on one machine yesterday, but not the other one I
      used this morning, sorry.
      
      [PATCH V5 net-next] neigh: new unresolved queue limits
      
      unres_qlen is the number of frames we are able to queue per unresolved
      neighbour. Its default value (3) was never changed and is responsible
      for strange drops, especially if IP fragments are used, or multiple
      sessions start in parallel. Even a single tcp flow can hit this limit.
      
      $ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
      8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b5c171b
  31. 27 7月, 2011 1 次提交
  32. 18 7月, 2011 1 次提交
  33. 17 7月, 2011 1 次提交