1. 21 10月, 2016 1 次提交
  2. 30 9月, 2016 1 次提交
  3. 16 6月, 2016 2 次提交
  4. 11 2月, 2016 1 次提交
  5. 05 1月, 2016 1 次提交
    • C
      soreuseport: fast reuseport UDP socket selection · e32ea7e7
      Craig Gallek 提交于
      Include a struct sock_reuseport instance when a UDP socket binds to
      a specific address for the first time with the reuseport flag set.
      When selecting a socket for an incoming UDP packet, use the information
      available in sock_reuseport if present.
      
      This required adding an additional field to the UDP source address
      equality function to differentiate between exact and wildcard matches.
      The original use case allowed wildcard matches when checking for
      existing port uses during bind.  The new use case of adding a socket
      to a reuseport group requires exact address matching.
      
      Performance test (using a machine with 2 CPU sockets and a total of
      48 cores):  Create reuseport groups of varying size.  Use one socket
      from this group per user thread (pinning each thread to a different
      core) calling recvmmsg in a tight loop.  Record number of messages
      received per second while saturating a 10G link.
        10 sockets: 18% increase (~2.8M -> 3.3M pkts/s)
        20 sockets: 14% increase (~2.9M -> 3.3M pkts/s)
        40 sockets: 13% increase (~3.0M -> 3.4M pkts/s)
      
      This work is based off a similar implementation written by
      Ying Cai <ycai@google.com> for implementing policy-based reuseport
      selection.
      Signed-off-by: NCraig Gallek <kraig@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e32ea7e7
  6. 25 9月, 2015 1 次提交
  7. 31 8月, 2015 1 次提交
  8. 01 8月, 2015 1 次提交
    • R
      ipv6: change ipv6_stub_impl.ipv6_dst_lookup to take net argument · 343d60aa
      Roopa Prabhu 提交于
      This patch adds net argument to ipv6_stub_impl.ipv6_dst_lookup
      for use cases where sk is not available (like mpls).
      sk appears to be needed to get the namespace 'net' and is optional
      otherwise. This patch series changes ipv6_stub_impl.ipv6_dst_lookup
      to take net argument. sk remains optional.
      
      All callers of ipv6_stub_impl.ipv6_dst_lookup have been modified
      to pass net. I have modified them to use already available
      'net' in the scope of the call. I can change them to
      sock_net(sk) to avoid any unintended change in behaviour if sock
      namespace is different. They dont seem to be from code inspection.
      Signed-off-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      343d60aa
  9. 05 5月, 2015 1 次提交
    • L
      net: Export IGMP/MLD message validation code · 9afd85c9
      Linus Lüssing 提交于
      With this patch, the IGMP and MLD message validation functions are moved
      from the bridge code to IPv4/IPv6 multicast files. Some small
      refactoring was done to enhance readibility and to iron out some
      differences in behaviour between the IGMP and MLD parsing code (e.g. the
      skb-cloning of MLD messages is now only done if necessary, just like the
      IGMP part always did).
      
      Finally, these IGMP and MLD message validation functions are exported so
      that not only the bridge can use it but batman-adv later, too.
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9afd85c9
  10. 06 2月, 2015 1 次提交
    • E
      net: ipv6: allow explicitly choosing optimistic addresses · c58da4c6
      Erik Kline 提交于
      RFC 4429 ("Optimistic DAD") states that optimistic addresses
      should be treated as deprecated addresses.  From section 2.1:
      
         Unless noted otherwise, components of the IPv6 protocol stack
         should treat addresses in the Optimistic state equivalently to
         those in the Deprecated state, indicating that the address is
         available for use but should not be used if another suitable
         address is available.
      
      Optimistic addresses are indeed avoided when other addresses are
      available (i.e. at source address selection time), but they have
      not heretofore been available for things like explicit bind() and
      sendmsg() with struct in6_pktinfo, etc.
      
      This change makes optimistic addresses treated more like
      deprecated addresses than tentative ones.
      Signed-off-by: NErik Kline <ek@google.com>
      Acked-by: NLorenzo Colitti <lorenzo@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c58da4c6
  11. 14 9月, 2014 1 次提交
  12. 13 9月, 2014 1 次提交
  13. 01 5月, 2014 1 次提交
  14. 28 2月, 2014 1 次提交
    • B
      ipv6: addrconf: silence sparse endianness warnings · bc861959
      Bjørn Mork 提交于
      Avoid the following sparse __CHECK_ENDIAN__ warnings:
      
       include/net/addrconf.h:318:25: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:318:70: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:330:25: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:330:70: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:347:25: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:348:26: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:349:18: warning: restricted __be64 degrades to integer
      
      The warnings are false but they make it harder to spot real
      bugs.
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc861959
  15. 23 1月, 2014 1 次提交
  16. 10 12月, 2013 1 次提交
  17. 07 12月, 2013 1 次提交
  18. 29 9月, 2013 1 次提交
  19. 01 9月, 2013 3 次提交
  20. 01 8月, 2013 1 次提交
  21. 02 7月, 2013 1 次提交
    • A
      ipv6,mcast: always hold idev->lock before mca_lock · 8965779d
      Amerigo Wang 提交于
      dingtianhong reported the following deadlock detected by lockdep:
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.4.24.05-0.1-default #1 Not tainted
       -------------------------------------------------------
       ksoftirqd/0/3 is trying to acquire lock:
        (&ndev->lock){+.+...}, at: [<ffffffff8147f804>] ipv6_get_lladdr+0x74/0x120
      
       but task is already holding lock:
        (&mc->mca_lock){+.+...}, at: [<ffffffff8149d130>] mld_send_report+0x40/0x150
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&mc->mca_lock){+.+...}:
              [<ffffffff810a8027>] validate_chain+0x637/0x730
              [<ffffffff810a8417>] __lock_acquire+0x2f7/0x500
              [<ffffffff810a8734>] lock_acquire+0x114/0x150
              [<ffffffff814f691a>] rt_spin_lock+0x4a/0x60
              [<ffffffff8149e4bb>] igmp6_group_added+0x3b/0x120
              [<ffffffff8149e5d8>] ipv6_mc_up+0x38/0x60
              [<ffffffff81480a4d>] ipv6_find_idev+0x3d/0x80
              [<ffffffff81483175>] addrconf_notify+0x3d5/0x4b0
              [<ffffffff814fae3f>] notifier_call_chain+0x3f/0x80
              [<ffffffff81073471>] raw_notifier_call_chain+0x11/0x20
              [<ffffffff813d8722>] call_netdevice_notifiers+0x32/0x60
              [<ffffffff813d92d4>] __dev_notify_flags+0x34/0x80
              [<ffffffff813d9360>] dev_change_flags+0x40/0x70
              [<ffffffff813ea627>] do_setlink+0x237/0x8a0
              [<ffffffff813ebb6c>] rtnl_newlink+0x3ec/0x600
              [<ffffffff813eb4d0>] rtnetlink_rcv_msg+0x160/0x310
              [<ffffffff814040b9>] netlink_rcv_skb+0x89/0xb0
              [<ffffffff813eb357>] rtnetlink_rcv+0x27/0x40
              [<ffffffff81403e20>] netlink_unicast+0x140/0x180
              [<ffffffff81404a9e>] netlink_sendmsg+0x33e/0x380
              [<ffffffff813c4252>] sock_sendmsg+0x112/0x130
              [<ffffffff813c537e>] __sys_sendmsg+0x44e/0x460
              [<ffffffff813c5544>] sys_sendmsg+0x44/0x70
              [<ffffffff814feab9>] system_call_fastpath+0x16/0x1b
      
       -> #0 (&ndev->lock){+.+...}:
              [<ffffffff810a798e>] check_prev_add+0x3de/0x440
              [<ffffffff810a8027>] validate_chain+0x637/0x730
              [<ffffffff810a8417>] __lock_acquire+0x2f7/0x500
              [<ffffffff810a8734>] lock_acquire+0x114/0x150
              [<ffffffff814f6c82>] rt_read_lock+0x42/0x60
              [<ffffffff8147f804>] ipv6_get_lladdr+0x74/0x120
              [<ffffffff8149b036>] mld_newpack+0xb6/0x160
              [<ffffffff8149b18b>] add_grhead+0xab/0xc0
              [<ffffffff8149d03b>] add_grec+0x3ab/0x460
              [<ffffffff8149d14a>] mld_send_report+0x5a/0x150
              [<ffffffff8149f99e>] igmp6_timer_handler+0x4e/0xb0
              [<ffffffff8105705a>] call_timer_fn+0xca/0x1d0
              [<ffffffff81057b9f>] run_timer_softirq+0x1df/0x2e0
              [<ffffffff8104e8c7>] handle_pending_softirqs+0xf7/0x1f0
              [<ffffffff8104ea3b>] __do_softirq_common+0x7b/0xf0
              [<ffffffff8104f07f>] __thread_do_softirq+0x1af/0x210
              [<ffffffff8104f1c1>] run_ksoftirqd+0xe1/0x1f0
              [<ffffffff8106c7de>] kthread+0xae/0xc0
              [<ffffffff814fff74>] kernel_thread_helper+0x4/0x10
      
      actually we can just hold idev->lock before taking pmc->mca_lock,
      and avoid taking idev->lock again when iterating idev->addr_list,
      since the upper callers of mld_newpack() already take
      read_lock_bh(&idev->lock).
      Reported-by: Ndingtianhong <dingtianhong@huawei.com>
      Cc: dingtianhong <dingtianhong@huawei.com>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Tested-by: NDing Tianhong <dingtianhong@huawei.com>
      Tested-by: NChen Weilong <chenweilong@huawei.com>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8965779d
  22. 29 6月, 2013 1 次提交
  23. 23 5月, 2013 1 次提交
    • F
      netfilter: add nf_ipv6_ops hook to fix xt_addrtype with IPv6 · 2a7851bf
      Florian Westphal 提交于
      Quoting https://bugzilla.netfilter.org/show_bug.cgi?id=812:
      
      [ ip6tables -m addrtype ]
      When I tried to use in the nat/PREROUTING it messes up the
      routing cache even if the rule didn't matched at all.
      [..]
      If I remove the --limit-iface-in from the non-working scenario, so just
      use the -m addrtype --dst-type LOCAL it works!
      
      This happens when LOCAL type matching is requested with --limit-iface-in,
      and the default ipv6 route is via the interface the packet we test
      arrived on.
      
      Because xt_addrtype uses ip6_route_output, the ipv6 routing implementation
      creates an unwanted cached entry, and the packet won't make it to the
      real/expected destination.
      
      Silently ignoring --limit-iface-in makes the routing work but it breaks
      rule matching (--dst-type LOCAL with limit-iface-in is supposed to only
      match if the dst address is configured on the incoming interface;
      without --limit-iface-in it will match if the address is reachable
      via lo).
      
      The test should call ipv6_chk_addr() instead.  However, this would add
      a link-time dependency on ipv6.
      
      There are two possible solutions:
      
      1) Revert the commit that moved ipt_addrtype to xt_addrtype,
         and put ipv6 specific code into ip6t_addrtype.
      2) add new "nf_ipv6_ops" struct to register pointers to ipv6 functions.
      
      While the former might seem preferable, Pablo pointed out that there
      are more xt modules with link-time dependeny issues regarding ipv6,
      so lets go for 2).
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      2a7851bf
  24. 15 4月, 2013 1 次提交
    • C
      ipv6: statically link register_inet6addr_notifier() · f88c91dd
      Cong Wang 提交于
      Tomas reported the following build error:
      
      net/built-in.o: In function `ieee80211_unregister_hw':
      (.text+0x10f0e1): undefined reference to `unregister_inet6addr_notifier'
      net/built-in.o: In function `ieee80211_register_hw':
      (.text+0x10f610): undefined reference to `register_inet6addr_notifier'
      make: *** [vmlinux] Error 1
      
      when built IPv6 as a module.
      
      So we have to statically link these symbols.
      Reported-by: NTomas Melin <tomas.melin@iki.fi>
      Cc: Tomas Melin <tomas.melin@iki.fi>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: YOSHIFUJI Hidaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f88c91dd
  25. 30 1月, 2013 1 次提交
    • J
      ipv4: introduce address lifetime · 5c766d64
      Jiri Pirko 提交于
      There are some usecase when lifetime of ipv4 addresses might be helpful.
      For example:
      1) initramfs networkmanager uses a DHCP daemon to learn network
      configuration parameters
      2) initramfs networkmanager addresses, routes and DNS configuration
      3) initramfs networkmanager is requested to stop
      4) initramfs networkmanager stops all daemons including dhclient
      5) there are addresses and routes configured but no daemon running. If
      the system doesn't start networkmanager for some reason, addresses and
      routes will be used forever, which violates RFC 2131.
      
      This patch is essentially a backport of ivp6 address lifetime mechanism
      for ipv4 addresses.
      
      Current "ip" tool supports this without any patch (since it does not
      distinguish between ipv4 and ipv6 addresses in this perspective.
      
      Also, this should be back-compatible with all current netlink users.
      Reported-by: NPavel Šimerda <psimerda@redhat.com>
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c766d64
  26. 21 1月, 2013 4 次提交
  27. 14 1月, 2013 1 次提交
  28. 05 12月, 2012 1 次提交
  29. 30 8月, 2012 1 次提交
  30. 19 7月, 2012 1 次提交
    • E
      ipv6: add ipv6_addr_hash() helper · ddbe5032
      Eric Dumazet 提交于
      Introduce ipv6_addr_hash() helper doing a XOR on all bits
      of an IPv6 address, with an optimized x86_64 version.
      
      Use it in flow dissector, as suggested by Andrew McGregor,
      to reduce hash collision probabilities in fq_codel (and other
      users of flow dissector)
      
      Use it in ip6_tunnel.c and use more bit shuffling, as suggested
      by David Laight, as existing hash was ignoring most of them.
      
      Use it in sunrpc and use more bit shuffling, using hash_32().
      
      Use it in net/ipv6/addrconf.c, using hash_32() as well.
      
      As a cleanup, use it in net/ipv4/tcp_metrics.c
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NAndrew McGregor <andrewmcgr@gmail.com>
      Cc: Dave Taht <dave.taht@gmail.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddbe5032
  31. 19 5月, 2012 1 次提交
  32. 16 4月, 2012 1 次提交
  33. 02 2月, 2012 1 次提交
  34. 05 1月, 2012 1 次提交
    • N
      ipv6: Check RA for sllao when configuring optimistic ipv6 address (v2) · e6bff995
      Neil Horman 提交于
      Recently Dave noticed that a test we did in ipv6_add_addr to see if we next hop
      route for the interface we're adding an addres to was wrong (see commit
      7ffbcecb).  for one, it never triggers, and two,
      it was completely wrong to begin with.  This test was meant to cover this
      section of RFC 4429:
      
      3.3 Modifications to RFC 2462 Stateless Address Autoconfiguration
      
         * (modifies section 5.5) A host MAY choose to configure a new address
              as an Optimistic Address.  A host that does not know the SLLAO
              of its router SHOULD NOT configure a new address as Optimistic.
              A router SHOULD NOT configure an Optimistic Address.
      
      This patch should bring us into proper compliance with the above clause.  Since
      we only add a SLAAC address after we've received a RA which may or may not
      contain a source link layer address option, we can pass a pointer to that option
      to addrconf_prefix_rcv (which may be null if the option is not present), and
      only set the optimistic flag if the option was found in the RA.
      
      Change notes:
      (v2) modified the new parameter to addrconf_prefix_rcv to be a bool rather than
      a pointer to make its use more clear as per request from davem.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e6bff995