1. 07 12月, 2011 1 次提交
  2. 06 12月, 2011 1 次提交
  3. 23 11月, 2011 1 次提交
  4. 01 11月, 2011 1 次提交
  5. 30 10月, 2011 1 次提交
    • A
      ipv6: fix route lookup in addrconf_prefix_rcv() · 14ef37b6
      Andreas Hofmeister 提交于
      The route lookup to find a previously auto-configured route for a prefixes used
      to use rt6_lookup(), with the prefix from the RA used as an address. However,
      that kind of lookup ignores routing tables, the prefix length and route flags,
      so when there were other matching routes, even in different tables and/or with
      a different prefix length, the wrong route would be manipulated.
      
      Now, a new function "addrconf_get_prefix_route()" is used for the route lookup,
      which searches in RT6_TABLE_PREFIX and takes the prefix-length and route flags
      into account.
      Signed-off-by: NAndreas Hofmeister <andi@collax.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14ef37b6
  6. 21 9月, 2011 1 次提交
  7. 17 9月, 2011 1 次提交
    • T
      ipv6: Send ICMPv6 RSes only when RAs are accepted · 026359bc
      Tore Anderson 提交于
      This patch improves the logic determining when to send ICMPv6 Router
      Solicitations, so that they are 1) always sent when the kernel is
      accepting Router Advertisements, and 2) never sent when the kernel is
      not accepting RAs. In other words, the operational setting of the
      "accept_ra" sysctl is used.
      
      The change also makes the special "Hybrid Router" forwarding mode
      ("forwarding" sysctl set to 2) operate exactly the same as the standard
      Router mode (forwarding=1). The only difference between the two was
      that RSes was being sent in the Hybrid Router mode only. The sysctl
      documentation describing the special Hybrid Router mode has therefore
      been removed.
      
      Rationale for the change:
      
      Currently, the value of forwarding sysctl is the only thing determining
      whether or not to send RSes. If it has the value 0 or 2, they are sent,
      otherwise they are not. This leads to inconsistent behaviour in the
      following cases:
      
      * accept_ra=0, forwarding=0
      * accept_ra=0, forwarding=2
      * accept_ra=1, forwarding=2
      * accept_ra=2, forwarding=1
      
      In the first three cases, the kernel will send RSes, even though it will
      not accept any RAs received in reply. In the last case, it will not send
      any RSes, even though it will accept and process any RAs received. (Most
      routers will send unsolicited RAs periodically, so suppressing RSes in
      the last case will merely delay auto-configuration, not prevent it.)
      
      Also, it is my opinion that having the forwarding sysctl control RS
      sending behaviour (completely independent of whether RAs are being
      accepted or not) is simply not what most users would intuitively expect
      to be the case.
      Signed-off-by: NTore Anderson <tore@fud.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      026359bc
  8. 03 8月, 2011 1 次提交
  9. 02 8月, 2011 2 次提交
  10. 26 7月, 2011 1 次提交
    • Y
      ipv6: Do not leave router anycast address for /127 prefixes. · 32019e65
      YOSHIFUJI Hideaki 提交于
      Original commit 2bda8a0c... "Disable router anycast
      address for /127 prefixes" says:
      
      |   No need for matching code in addrconf_leave_anycast() as it
      |   will silently ignore any attempt to leave an unknown anycast
      |   address.
      
      After analysis, because 1) we may add two or more prefixes on the
      same interface, or 2)user may have manually joined that anycast,
      we may hit chances to have anycast address which as if we had
      generated one by /127 prefix and we should not leave from subnet-
      router anycast address unconditionally.
      
      CC: Bjørn Mork <bjorn@mork.no>
      CC: Brian Haley <brian.haley@hp.com>
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32019e65
  11. 18 7月, 2011 2 次提交
  12. 07 7月, 2011 1 次提交
  13. 10 6月, 2011 1 次提交
    • G
      rtnetlink: Compute and store minimum ifinfo dump size · c7ac8679
      Greg Rose 提交于
      The message size allocated for rtnl ifinfo dumps was limited to
      a single page.  This is not enough for additional interface info
      available with devices that support SR-IOV and caused a bug in
      which VF info would not be displayed if more than approximately
      40 VFs were created per interface.
      
      Implement a new function pointer for the rtnl_register service that will
      calculate the amount of data required for the ifinfo dump and allocate
      enough data to satisfy the request.
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c7ac8679
  14. 09 6月, 2011 1 次提交
  15. 20 5月, 2011 1 次提交
    • E
      ipv6: reduce per device ICMP mib sizes · be281e55
      Eric Dumazet 提交于
      ipv6 has per device ICMP SNMP counters, taking too much space because
      they use percpu storage.
      
      needed size per device is :
      (512+4)*sizeof(long)*number_of_possible_cpus*2
      
      On a 32bit kernel, 16 possible cpus, this wastes more than 64kbytes of
      memory per ipv6 enabled network device, taken in vmalloc pool.
      
      Since ICMP messages are rare, just use shared counters (atomic_long_t)
      
      Per network space ICMP counters are still using percpu memory, we might
      also convert them to shared counters in a future patch.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Denys Fedoryshchenko <denys@visp.net.lb>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be281e55
  16. 08 5月, 2011 2 次提交
  17. 03 5月, 2011 1 次提交
  18. 23 4月, 2011 1 次提交
  19. 16 4月, 2011 1 次提交
  20. 31 3月, 2011 1 次提交
  21. 26 2月, 2011 1 次提交
  22. 26 1月, 2011 1 次提交
  23. 19 1月, 2011 1 次提交
    • R
      ipv6: Silence privacy extensions initialization · 2fdc1c80
      Romain Francoise 提交于
      When a network namespace is created (via CLONE_NEWNET), the loopback
      interface is automatically added to the new namespace, triggering a
      printk in ipv6_add_dev() if CONFIG_IPV6_PRIVACY is set.
      
      This is problematic for applications which use CLONE_NEWNET as
      part of a sandbox, like Chromium's suid sandbox or recent versions of
      vsftpd. On a busy machine, it can lead to thousands of useless
      "lo: Disabled Privacy Extensions" messages appearing in dmesg.
      
      It's easy enough to check the status of privacy extensions via the
      use_tempaddr sysctl, so just removing the printk seems like the most
      sensible solution.
      Signed-off-by: NRomain Francoise <romain@orebokech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fdc1c80
  24. 19 12月, 2010 1 次提交
  25. 17 12月, 2010 1 次提交
  26. 11 12月, 2010 1 次提交
  27. 28 11月, 2010 1 次提交
    • T
      rtnl: make link af-specific updates atomic · cf7afbfe
      Thomas Graf 提交于
      As David pointed out correctly, updates to af-specific attributes
      are currently not atomic. If multiple changes are requested and
      one of them fails, previous updates may have been applied already
      leaving the link behind in a undefined state.
      
      This patch splits the function parse_link_af() into two functions
      validate_link_af() and set_link_at(). validate_link_af() is placed
      to validate_linkmsg() check for errors as early as possible before
      any changes to the link have been made. set_link_af() is called to
      commit the changes later.
      
      This method is not fail proof, while it is currently sufficient
      to make set_link_af() inerrable and thus 100% atomic, the
      validation function method will not be able to detect all error
      scenarios in the future, there will likely always be errors
      depending on states which are f.e. not protected by rtnl_mutex
      and thus may change between validation and setting.
      
      Also, instead of silently ignoring unknown address families and
      config blocks for address families which did not register a set
      function the errors EAFNOSUPPORT respectively EOPNOSUPPORT are
      returned to avoid comitting 4 out of 5 update requests without
      notifying the user.
      Signed-off-by: NThomas Graf <tgraf@infradead.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf7afbfe
  28. 22 11月, 2010 1 次提交
  29. 19 11月, 2010 2 次提交
  30. 18 11月, 2010 1 次提交
  31. 17 11月, 2010 1 次提交
  32. 13 11月, 2010 1 次提交
    • L
      ipv6: addrconf: don't remove address state on ifdown if the address is being kept · 2de79570
      Lorenzo Colitti 提交于
      Currently, addrconf_ifdown does not delete statically configured IPv6
      addresses when the interface is brought down. The intent is that when
      the interface comes back up the address will be usable again. However,
      this doesn't actually work, because the system stops listening on the
      corresponding solicited-node multicast address, so the address cannot
      respond to neighbor solicitations and thus receive traffic. Also, the
      code notifies the rest of the system that the address is being deleted
      (e.g, RTM_DELADDR), even though it is not. Fix it so that none of this
      state is updated if the address is being kept on the interface.
      
      Tested: Added a statically configured IPv6 address to an interface,
      started ping, brought link down, brought link up again. When link came
      up ping kept on going and "ip -6 maddr" showed that the host was still
      subscribed to there
      Signed-off-by: NLorenzo Colitti <lorenzo@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2de79570
  33. 28 10月, 2010 1 次提交
  34. 27 10月, 2010 2 次提交
  35. 05 10月, 2010 1 次提交