1. 11 7月, 2007 1 次提交
    • J
      bonding / ipv6: no addrconf for slaves separately from master · c2edacf8
      Jay Vosburgh 提交于
      	At present, when a device is enslaved to bonding, if ipv6 is
      active then addrconf will be initated on the slave (because it is closed
      then opened during the enslavement processing).  This causes DAD and RS
      packets to be sent from the slave.  These packets in turn can confuse
      switches that perform ipv6 snooping, causing them to incorrectly update
      their forwarding tables (if, e.g., the slave being added is an inactve
      backup that won't be used right away) and direct traffic away from the
      active slave to a backup slave (where the incoming packets will be
      dropped).
      
      	This patch alters the behavior so that addrconf will only run on
      the master device itself.  I believe this is logically correct, as it
      prevents slaves from having an IPv6 identity independent from the
      master.  This is consistent with the IPv4 behavior for bonding.
      
      	This is accomplished by (a) having bonding set IFF_SLAVE sooner
      in the enslavement processing than currently occurs (before open, not
      after), and (b) having ipv6 addrconf ignore UP and CHANGE events on
      slave devices.
      
      	The eql driver also uses the IFF_SLAVE flag.  I inspected eql,
      and I believe this change is reasonable for its usage of IFF_SLAVE, but
      I did not test it.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      c2edacf8
  2. 15 6月, 2007 1 次提交
    • H
      [IPV6] addrconf: Fix IPv6 on tuntap tunnels · 74235a25
      Herbert Xu 提交于
      The recent patch that added ipv6_hwtype is broken on tuntap tunnels.
      Indeed, it's broken on any device that does not pass the ipv6_hwtype
      test.
      
      The reason is that the original test only applies to autoconfiguration,
      not IPv6 support.  IPv6 support is allowed on any device.  In fact,
      even with the ipv6_hwtype patch applied you can still add IPv6 addresses
      to any interface that doesn't pass thw ipv6_hwtype test provided that
      they have a sufficiently large MTU.  This is a serious problem because
      come deregistration time these devices won't be cleaned up properly.
      
      I've gone back and looked at the rationale for the patch.  It appears
      that the real problem is that we were creating IPv6 devices even if the
      MTU was too small.  So here's a patch which fixes that and reverts the
      ipv6_hwtype stuff.
      
      Thanks to Kanru Chen for reporting this issue.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74235a25
  3. 08 6月, 2007 1 次提交
  4. 25 5月, 2007 1 次提交
  5. 11 5月, 2007 1 次提交
  6. 04 5月, 2007 1 次提交
  7. 29 4月, 2007 1 次提交
  8. 26 4月, 2007 8 次提交
  9. 25 4月, 2007 1 次提交
  10. 28 3月, 2007 1 次提交
  11. 23 3月, 2007 1 次提交
  12. 08 3月, 2007 1 次提交
  13. 01 3月, 2007 1 次提交
  14. 27 2月, 2007 3 次提交
  15. 15 2月, 2007 3 次提交
  16. 13 2月, 2007 1 次提交
  17. 11 2月, 2007 1 次提交
  18. 09 2月, 2007 1 次提交
    • P
      [NETLINK]: Don't BUG on undersized allocations · 26932566
      Patrick McHardy 提交于
      Currently netlink users BUG when the allocated skb for an event
      notification is undersized. While this is certainly a kernel bug,
      its not critical and crashing the kernel is too drastic, especially
      when considering that these errors have appeared multiple times in
      the past and it BUGs even if no listeners are present.
      
      This patch replaces BUG by WARN_ON and changes the notification
      functions to inform potential listeners of undersized allocations
      using a unique error code (EMSGSIZE).
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26932566
  19. 31 1月, 2007 1 次提交
  20. 24 1月, 2007 1 次提交
  21. 05 1月, 2007 1 次提交
  22. 11 12月, 2006 1 次提交
  23. 03 12月, 2006 6 次提交
  24. 12 10月, 2006 1 次提交