1. 26 7月, 2016 1 次提交
  2. 15 7月, 2016 1 次提交
    • B
      bonding: set carrier off for devices created through netlink · 005db31d
      Beniamino Galvani 提交于
      Commit e826eafa ("bonding: Call netif_carrier_off after
      register_netdevice") moved netif_carrier_off() from bond_init() to
      bond_create(), but the latter is called only for initial default
      devices and ones created through sysfs:
      
       $ modprobe bonding
       $ echo +bond1 > /sys/class/net/bonding_masters
       $ ip link add bond2 type bond
       $ grep "MII Status" /proc/net/bonding/*
       /proc/net/bonding/bond0:MII Status: down
       /proc/net/bonding/bond1:MII Status: down
       /proc/net/bonding/bond2:MII Status: up
      
      Ensure that carrier is initially off also for devices created through
      netlink.
      Signed-off-by: NBeniamino Galvani <bgalvani@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      005db31d
  3. 06 7月, 2016 2 次提交
  4. 01 7月, 2016 1 次提交
  5. 28 6月, 2016 1 次提交
    • J
      bonding: fix 802.3ad aggregator reselection · 0622cab0
      Jay Vosburgh 提交于
      Since commit 7bb11dc9 ("bonding: unify all places where
      actor-oper key needs to be updated."), the logic in bonding to handle
      selection between multiple aggregators has not functioned.
      
      	This affects only configurations wherein the bonding slaves
      connect to two discrete aggregators (e.g., two independent switches, each
      with LACP enabled), thus creating two separate aggregation groups within a
      single bond.
      
      	The cause is a change in 7bb11dc9 to no longer set
      AD_PORT_BEGIN on a port after a link state change, which would cause the
      port to be reselected for attachment to an aggregator as if were newly
      added to the bond.  We cannot restore the prior behavior, as it
      contradicts IEEE 802.1AX 5.4.12, which requires ports that "become
      inoperable" (lose carrier, setting port_enabled=false as per 802.1AX
      5.4.7) to remain selected (i.e., assigned to the aggregator).  As the port
      now remains selected, the aggregator selection logic is not invoked.
      
      	A side effect of this change is that aggregators in bonding will
      now contain ports that are link down.  The aggregator selection logic
      does not currently handle this situation correctly, causing incorrect
      aggregator selection.
      
      	This patch makes two changes to repair the aggregator selection
      logic in bonding to function as documented and within the confines of the
      standard:
      
      	First, the aggregator selection and related logic now utilizes the
      number of active ports per aggregator, not the number of selected ports
      (as some selected ports may be down).  The ad_select "bandwidth" and
      "count" options only consider ports that are link up.
      
      	Second, on any carrier state change of any slave, the aggregator
      selection logic is explicitly called to insure the correct aggregator is
      active.
      Reported-by: NVeli-Matti Lintu <veli-matti.lintu@opinsys.fi>
      Fixes: 7bb11dc9 ("bonding: unify all places where actor-oper key needs to be updated.")
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0622cab0
  6. 10 6月, 2016 1 次提交
  7. 08 6月, 2016 1 次提交
  8. 19 3月, 2016 2 次提交
  9. 26 2月, 2016 1 次提交
  10. 17 2月, 2016 1 次提交
    • J
      bonding: don't use stale speed and duplex information · 266b495f
      Jay Vosburgh 提交于
      There is presently a race condition between the bonding periodic
      link monitor and the updating of a slave's speed and duplex.  The former
      occurs on a periodic basis, and the latter in response to a driver's
      calling of netif_carrier_on.
      
      	It is possible for the periodic monitor to run between the
      driver call of netif_carrier_on and the receipt of the NETDEV_CHANGE
      event that causes bonding to update the slave's speed and duplex.  This
      manifests most notably as a report that a slave is up and "0 Mbps full
      duplex" after enslavement, but in principle could report an incorrect
      speed and duplex after any link up event if the device comes up with a
      different speed or duplex.  This affects the 802.3ad aggregator
      selection, as the speed and duplex are selection criteria.
      
      	This is fixed by updating the speed and duplex in the periodic
      monitor, prior to using that information.
      
      	This was done historically in bonding, but the call to
      bond_update_speed_duplex was removed in commit 876254ae ("bonding:
      don't call update_speed_duplex() under spinlocks"), as it might sleep
      under lock.  Later, the locking was changed to only hold RTNL, and so
      after commit 876254ae ("bonding: don't call update_speed_duplex()
      under spinlocks") this call is again safe.
      Tested-by: N"Tantilov, Emil S" <emil.s.tantilov@intel.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: dingtianhong <dingtianhong@huawei.com>
      Fixes: 876254ae ("bonding: don't call update_speed_duplex() under spinlocks")
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Acked-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      266b495f
  11. 13 2月, 2016 1 次提交
    • J
      bonding: Fix ARP monitor validation · 21a75f09
      Jay Vosburgh 提交于
      The current logic in bond_arp_rcv will accept an incoming ARP for
      validation if (a) the receiving slave is either "active" (which includes
      the currently active slave, or the current ARP slave) or, (b) there is a
      currently active slave, and it has received an ARP since it became active.
      For case (b), the receiving slave isn't the currently active slave, and is
      receiving the original broadcast ARP request, not an ARP reply from the
      target.
      
      	This logic can fail if there is no currently active slave.  In
      this situation, the ARP probe logic cycles through all slaves, assigning
      each in turn as the "current_arp_slave" for one arp_interval, then setting
      that one as "active," and sending an ARP probe from that slave.  The
      current logic expects the ARP reply to arrive on the sending
      current_arp_slave, however, due to switch FDB updating delays, the reply
      may be directed to another slave.
      
      	This can arise if the bonding slaves and switch are working, but
      the ARP target is not responding.  When the ARP target recovers, a
      condition may result wherein the ARP target host replies faster than the
      switch can update its forwarding table, causing each ARP reply to be sent
      to the previous current_arp_slave.  This will never pass the logic in
      bond_arp_rcv, as neither of the above conditions (a) or (b) are met.
      
      	Some experimentation on a LAN shows ARP reply round trips in the
      200 usec range, but my available switches never update their FDB in less
      than 4000 usec.
      
      	This patch changes the logic in bond_arp_rcv to additionally
      accept an ARP reply for validation on any slave if there is a current ARP
      slave and it sent an ARP probe during the previous arp_interval.
      
      Fixes: aeea64ac ("bonding: don't trust arp requests unless active slave really works")
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21a75f09
  12. 11 2月, 2016 3 次提交
  13. 09 2月, 2016 1 次提交
  14. 08 2月, 2016 1 次提交
  15. 06 2月, 2016 2 次提交
  16. 12 1月, 2016 2 次提交
    • K
      bonding: Prevent IPv6 link local address on enslaved devices · 03d84a5f
      Karl Heiss 提交于
      Commit 1f718f0f ("bonding: populate neighbour's private on enslave")
      undoes the fix provided by commit c2edacf8 ("bonding / ipv6: no addrconf
      for slaves separately from master") by effectively setting the slave flag
      after the slave has been opened.  If the slave comes up quickly enough, it
      will go through the IPv6 addrconf before the slave flag has been set and
      will get a link local IPv6 address.
      
      In order to ensure that addrconf knows to ignore the slave devices on state
      change, set IFF_SLAVE before dev_open() during bonding enslavement.
      
      Fixes: 1f718f0f ("bonding: populate neighbour's private on enslave")
      Signed-off-by: NKarl Heiss <kheiss@gmail.com>
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Reviewed-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NAndy Gospodarek <gospo@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03d84a5f
    • J
      bonding: make mii_status sysfs node consistent · c8086f6d
      Jarod Wilson 提交于
      The spew in /proc/net/bonding/bond0 uses netif_carrier_ok() to determine
      mii_status, while /sys/class/net/bond0/bonding/mii_status looks at
      curr_active_slave, which doesn't actually seem to be set sometimes when
      the bond actually is up. A mode 4 bond configured via ifcfg-foo files on a
      Red Hat Enterprise Linux system, after boot, comes up clean and
      functional, but the sysfs node shows mii_status of down, while proc shows
      up. A simple enough fix here seems to be to use the same method for
      determining up or down in both places, and I'd opt for the one that seems
      to match reality.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <gospo@cumulusnetworks.com>
      CC: netdev@vger.kernel.org
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8086f6d
  17. 24 12月, 2015 1 次提交
  18. 16 12月, 2015 1 次提交
    • T
      net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK · a188222b
      Tom Herbert 提交于
      The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
      set of features for offloading all checksums. This is a mask of the
      checksum offload related features bits. It is incorrect to set both
      NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
      features of a device.
      
      This patch:
        - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
          NETIF_F_ALL_CSUM is being used as a mask).
        - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
          use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a188222b
  19. 04 12月, 2015 8 次提交
  20. 08 11月, 2015 1 次提交
    • J
      bonding: fix panic on non-ARPHRD_ETHER enslave failure · 40baec22
      Jay Vosburgh 提交于
      Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
      are not ARPHRD_ETHER, if needed, it resets the bonding device back to
      ARPHRD_ETHER by calling ether_setup.
      
      	Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
      if the bond device is up, leaving it in a quasi-down state without
      having actually gone through dev_close.  For bonding, if any periodic
      work queue items are active (miimon, arp_interval, etc), those will
      remain running, as they are stopped by bond_close.  At this point, if
      the bonding module is unloaded or the bond is deleted, the system will
      panic when the work function is called.
      
      	This panic is resolved by calling dev_close on the bond itself
      prior to calling ether_setup.
      
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Fixes: 7d5cd2ce ("bonding: correctly handle bonding type change on enslave failure")
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40baec22
  21. 03 11月, 2015 3 次提交
  22. 16 10月, 2015 1 次提交
  23. 18 9月, 2015 1 次提交
    • E
      bonding: use l4 hash if available · 4b1b865e
      Eric Dumazet 提交于
      If skb carries a l4 hash, no need to perform a flow dissection.
      
      Performance is slightly better :
      
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.39012e+06
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.39393e+06
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.39988e+06
      
      After patch :
      
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.43579e+06
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.44304e+06
      lpaa5:~# ./super_netperf 200 -H lpaa6 -t TCP_RR -l 100
      2.44312e+06
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b1b865e
  24. 02 9月, 2015 1 次提交
  25. 31 8月, 2015 1 次提交