1. 09 3月, 2015 1 次提交
  2. 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
  3. 03 3月, 2015 3 次提交
  4. 19 1月, 2015 1 次提交
  5. 18 1月, 2015 1 次提交
    • J
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg 提交于
      Contrary to common expectations for an "int" return, these functions
      return only a positive value -- if used correctly they cannot even
      return 0 because the message header will necessarily be in the skb.
      
      This makes the very common pattern of
      
        if (genlmsg_end(...) < 0) { ... }
      
      be a whole bunch of dead code. Many places also simply do
      
        return nlmsg_end(...);
      
      and the caller is expected to deal with it.
      
      This also commonly (at least for me) causes errors, because it is very
      common to write
      
        if (my_function(...))
          /* error condition */
      
      and if my_function() does "return nlmsg_end()" this is of course wrong.
      
      Additionally, there's not a single place in the kernel that actually
      needs the message length returned, and if anyone needs it later then
      it'll be very easy to just use skb->len there.
      
      Remove this, and make the functions void. This removes a bunch of dead
      code as described above. The patch adds lines because I did
      
      -	return nlmsg_end(...);
      +	nlmsg_end(...);
      +	return 0;
      
      I could have preserved all the function's return values by returning
      skb->len, but instead I've audited all the places calling the affected
      functions and found that none cared. A few places actually compared
      the return value with <= 0 in dump functionality, but that could just
      be changed to < 0 with no change in behaviour, so I opted for the more
      efficient version.
      
      One instance of the error I've made numerous times now is also present
      in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
      check for <0 or <=0 and thus broke out of the loop every single time.
      I've preserved this since it will (I think) have caused the messages to
      userspace to be formatted differently with just a single message for
      every SKB returned to userspace. It's possible that this isn't needed
      for the tools that actually use this, but I don't even know what they
      are so couldn't test that changing this behaviour would be acceptable.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      053c095a
  6. 14 1月, 2015 1 次提交
    • J
      neighbour: fix base_reachable_time(_ms) not effective immediatly when changed · 4bf6980d
      Jean-Francois Remy 提交于
      When setting base_reachable_time or base_reachable_time_ms on a
      specific interface through sysctl or netlink, the reachable_time
      value is not updated.
      
      This means that neighbour entries will continue to be updated using the
      old value until it is recomputed in neigh_period_work (which
          recomputes the value every 300*HZ).
      On systems with HZ equal to 1000 for instance, it means 5mins before
      the change is effective.
      
      This patch changes this behavior by recomputing reachable_time after
      each set on base_reachable_time or base_reachable_time_ms.
      The new value will become effective the next time the neighbour's timer
      is triggered.
      
      Changes are made in two places: the netlink code for set and the sysctl
      handling code. For sysctl, I use a proc_handler. The ipv6 network
      code does provide its own handler but it already refreshes
      reachable_time correctly so it's not an issue.
      Any other user of neighbour which provide its own handlers must
      refresh reachable_time.
      Signed-off-by: NJean-Francois Remy <jeff@melix.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bf6980d
  7. 12 11月, 2014 1 次提交
  8. 30 10月, 2014 1 次提交
  9. 29 7月, 2014 1 次提交
  10. 15 7月, 2014 1 次提交
  11. 14 5月, 2014 1 次提交
    • D
      neigh: set nud_state to NUD_INCOMPLETE when probing router reachability · 2176d5d4
      Duan Jiong 提交于
      Since commit 7e980569("ipv6: router reachability probing"), a router falls
      into NUD_FAILED will be probed.
      
      Now if function rt6_select() selects a router which neighbour state is NUD_FAILED,
      and at the same time function rt6_probe() changes the neighbour state to NUD_PROBE,
      then function dst_neigh_output() can directly send packets, but actually the
      neighbour still is unreachable. If we set nud_state to NUD_INCOMPLETE instead
      NUD_PROBE, packets will not be sent out until the neihbour is reachable.
      
      In addition, because the route should be probes with a single NS, so we must
      set neigh->probes to neigh_max_probes(), then the neigh timer timeout and function
      neigh_timer_handler() will not send other NS Messages.
      Signed-off-by: NDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2176d5d4
  12. 28 2月, 2014 2 次提交
  13. 27 2月, 2014 1 次提交
  14. 22 2月, 2014 1 次提交
  15. 23 1月, 2014 1 次提交
    • V
      net/neighbour: queue work on power efficient wq · f618002b
      viresh kumar 提交于
      Workqueue used in neighbour layer have no real dependency of scheduling these on
      the cpu which scheduled them.
      
      On a idle system, it is observed that an idle cpu wakes up many times just to
      service this work. It would be better if we can schedule it on a cpu which the
      scheduler believes to be the most appropriate one.
      
      This patch replaces normal workqueues with power efficient versions. This
      doesn't change existing behavior of code unless CONFIG_WQ_POWER_EFFICIENT is
      enabled.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f618002b
  16. 16 1月, 2014 1 次提交
  17. 15 1月, 2014 1 次提交
  18. 01 1月, 2014 1 次提交
    • D
      vlan: Fix header ops passthru when doing TX VLAN offload. · 2205369a
      David S. Miller 提交于
      When the vlan code detects that the real device can do TX VLAN offloads
      in hardware, it tries to arrange for the real device's header_ops to
      be invoked directly.
      
      But it does so illegally, by simply hooking the real device's
      header_ops up to the VLAN device.
      
      This doesn't work because we will end up invoking a set of header_ops
      routines which expect a device type which matches the real device, but
      will see a VLAN device instead.
      
      Fix this by providing a pass-thru set of header_ops which will arrange
      to pass the proper real device instead.
      
      To facilitate this add a dev_rebuild_header().  There are
      implementations which provide a ->cache and ->create but not a
      ->rebuild (f.e. PLIP).  So we need a helper function just like
      dev_hard_header() to avoid crashes.
      
      Use this helper in the one existing place where the
      header_ops->rebuild was being invoked, the neighbour code.
      
      With lots of help from Florian Westphal.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2205369a
  19. 18 12月, 2013 1 次提交
    • B
      neigh: Netlink notification for administrative NUD state change · 53385d2d
      Bob Gilligan 提交于
      The neighbour code sends up an RTM_NEWNEIGH netlink notification if
      the NUD state of a neighbour cache entry is changed by a timer (e.g.
      from REACHABLE to STALE), even if the lladdr of the entry has not
      changed.
      
      But an administrative change to the the NUD state of a neighbour cache
      entry that does not change the lladdr (e.g. via "ip -4 neigh change
      ...  nud ...") does not trigger a netlink notification.  This means
      that netlink listeners will not hear about administrative NUD state
      changes such as from a resolved state to PERMANENT.
      
      This patch changes the neighbor code to generate an RTM_NEWNEIGH
      message when the NUD state of an entry is changed administratively.
      Signed-off-by: NBob Gilligan <gilligan@aristanetworks.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      53385d2d
  20. 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
  21. 11 12月, 2013 1 次提交
  22. 10 12月, 2013 5 次提交
  23. 27 9月, 2013 1 次提交
    • H
      net: neighbour: use source address of last enqueued packet for solicitation · 4ed377e3
      Hannes Frederic Sowa 提交于
      Currently we always use the first member of the arp_queue to determine
      the sender ip address of the arp packet (or in case of IPv6 - source
      address of the ndisc packet). This skb is fixed as long as the queue is
      not drained by a complete purge because of a timeout or by a successful
      response.
      
      If the first packet enqueued on the arp_queue is from a local application
      with a manually set source address and the to be discovered system
      does some kind of uRPF checks on the source address in the arp packet
      the resolving process hangs until a timeout and restarts. This hurts
      communication with the participating network node.
      
      This could be mitigated a bit if we use the latest enqueued skb's
      source address for the resolving process, which is not as static as
      the arp_queue's head. This change of the source address could result in
      better recovery of a failed solicitation.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Julian Anastasov <ja@ssi.bg>
      Reviewed-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ed377e3
  24. 04 9月, 2013 1 次提交
    • T
      net: neighbour: Remove CONFIG_ARPD · 3e25c65e
      Tim Gardner 提交于
      This config option is superfluous in that it only guards a call
      to neigh_app_ns(). Enabling CONFIG_ARPD by default has no
      change in behavior. There will now be call to __neigh_notify()
      for each ARP resolution, which has no impact unless there is a
      user space daemon waiting to receive the notification, i.e.,
      the case for which CONFIG_ARPD was designed anyways.
      Suggested-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: James Morris <jmorris@namei.org>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Gao feng <gaofeng@cn.fujitsu.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Veaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
      Reviewed-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e25c65e
  25. 06 8月, 2013 1 次提交
  26. 03 8月, 2013 1 次提交
  27. 27 7月, 2013 1 次提交
  28. 02 7月, 2013 1 次提交
  29. 20 6月, 2013 3 次提交
  30. 13 6月, 2013 1 次提交