1. 25 4月, 2014 1 次提交
  2. 19 3月, 2014 1 次提交
  3. 13 3月, 2014 1 次提交
  4. 27 2月, 2014 2 次提交
    • D
      bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for ab arp monitor · b0929915
      dingtianhong 提交于
      Veaceslav has reported and fix this problem by commit f2ebd477
      (bonding: restructure locking of bond_ab_arp_probe()). According Jay's
      opinion, the current solution is not very well, because the notification
      is to indicate that the interface has actually changed state in a meaningful
      way, but these calls in the ab ARP monitor are internal settings of the flags
      to allow the ARP monitor to search for a slave to become active when there are
      no active slaves. The flag setting to active or backup is to permit the ARP
      monitor's response logic to do the right thing when deciding if the test
      slave (current_arp_slave) is up or not.
      
      So the best way to fix the problem is that we should not send a notification
      when the slave is in testing state, and check the state at the end of the
      monitor, if the slave's state recover, avoid to send pointless notification
      twice. And RTNL is really a big lock, hold it regardless the slave's state
      changed or not when the current_active_slave is null will loss performance
      (every 100ms), so we should hold it only when the slave's state changed and
      need to notify.
      
      I revert the old commit and add new modifications.
      
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Veaceslav Falico <vfalico@redhat.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0929915
    • D
      bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for 802.3ad mode · 5e5b0665
      dingtianhong 提交于
      The problem was introduced by the commit 1d3ee88a
      (bonding: add netlink attributes to slave link dev).
      The bond_set_active_slave() and bond_set_backup_slave()
      will use rtmsg_ifinfo to send slave's states, so these
      two functions should be called in RTNL.
      
      In 802.3ad mode, acquiring RTNL for the __enable_port and
      __disable_port cases is difficult, as those calls generally
      already hold the state machine lock, and cannot unconditionally
      call rtnl_lock because either they already hold RTNL (for calls
      via bond_3ad_unbind_slave) or due to the potential for deadlock
      with bond_3ad_adapter_speed_changed, bond_3ad_adapter_duplex_changed,
      bond_3ad_link_change, or bond_3ad_update_lacp_rate.  All four of
      those are called with RTNL held, and acquire the state machine lock
      second.  The calling contexts for __enable_port and __disable_port
      already hold the state machine lock, and may or may not need RTNL.
      
      According to the Jay's opinion, I don't think it is a problem that
      the slave don't send notify message synchronously when the status
      changed, normally the state machine is running every 100 ms, send
      the notify message at the end of the state machine if the slave's
      state changed should be better.
      
      I fix the problem through these steps:
      
      1). add a new function bond_set_slave_state() which could change
          the slave's state and call rtmsg_ifinfo() according to the input
          parameters called notify.
      
      2). Add a new slave parameter which called should_notify, if the slave's state
          changed and don't notify yet, the parameter will be set to 1, and then if
          the slave's state changed again, the param will be set to 0, it indicate that
          the slave's state has been restored, no need to notify any one.
      
      3). the __enable_port and __disable_port should not call rtmsg_ifinfo
          in the state machine lock, any change in the state of slave could
          set a flag in the slave, it will indicated that an rtmsg_ifinfo
          should be called at the end of the state machine.
      
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Veaceslav Falico <vfalico@redhat.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e5b0665
  5. 20 2月, 2014 2 次提交
  6. 18 2月, 2014 1 次提交
    • J
      bonding: 802.3ad: make aggregator_identifier bond-private · 163c8ff3
      Jiri Bohac 提交于
      aggregator_identifier is used to assign unique aggregator identifiers
      to aggregators of a bond during device enslaving.
      
      aggregator_identifier is currently a global variable that is zeroed in
      bond_3ad_initialize().
      
      This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:
      
      create bond0
      change bond0 mode to 802.3ad
      enslave eth0 to bond0 		//eth0 gets agg id 1
      enslave eth1 to bond0 		//eth1 gets agg id 2
      create bond1
      change bond1 mode to 802.3ad
      enslave eth2 to bond1		//aggregator_identifier is reset to 0
      				//eth2 gets agg id 1
      enslave eth3 to bond0 		//eth3 gets agg id 2
      
      Fix this by making aggregator_identifier private to the bond.
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Acked-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      163c8ff3
  7. 17 2月, 2014 2 次提交
  8. 14 1月, 2014 3 次提交
    • V
      bonding: fix __get_active_agg() RCU logic · 49b7624e
      Veaceslav Falico 提交于
      Currently, the implementation is meaningless - once again, we take the
      slave structure and use it after we've exited RCU critical section.
      
      Fix this by removing the rcu_read_lock() from __get_active_agg(), and
      ensuring that all its callers are holding RCU.
      
      Fixes: be79bd04 ("bonding: add RCU for bond_3ad_state_machine_handler()")
      CC: dingtianhong@huawei.com
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49b7624e
    • V
      bonding: fix __get_first_agg RCU usage · 768b9549
      Veaceslav Falico 提交于
      Currently, the RCU read lock usage is just wrong - it gets the slave struct
      under RCU and continues to use it when RCU lock is released.
      
      However, it's still safe to do this cause we didn't need the
      rcu_read_lock() initially - all of the __get_first_agg() callers are either
      holding RCU read lock or the RTNL lock, so that we can't sync while in it.
      
      Fixes: be79bd04 ("bonding: add RCU for bond_3ad_state_machine_handler()")
      CC: dingtianhong@huawei.com
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      768b9549
    • V
      bonding: fix bond_3ad_set_carrier() RCU usage · c1bc9644
      Veaceslav Falico 提交于
      Currently, its usage is just plainly wrong. It first gets a slave under
      RCU, and, after releasing the RCU lock, continues to use it - whilst it can
      be freed.
      
      Fix this by ensuring that bond_3ad_set_carrier() holds RCU till it uses its
      slave (or its agg).
      
      Fixes: be79bd04 ("bonding: add RCU for bond_3ad_state_machine_handler()")
      CC: dingtianhong@huawei.com
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1bc9644
  9. 13 1月, 2014 3 次提交
  10. 02 1月, 2014 3 次提交
  11. 19 12月, 2013 3 次提交
    • D
      bonding: protect port for bond_3ad_handle_link_change() · 108db736
      dingtianhong 提交于
      The bond_3ad_handle_link_change is called with RTNL only,
      and the function will modify the port's information with
      no further locking, it will not mutex against bond state
      machine and incoming LACPDU which do not hold RTNL, So I
      add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup it and
      add a new pr_debug to debug the port message.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      108db736
    • D
      bonding: protect port for bond_3ad_adapter_duplex_changed() · bca44a73
      dingtianhong 提交于
      Jay Vosburgh said that the bond_3ad_adapter_duplex_changed is
      called with RTNL only, and the function will modify the port's
      information with no further locking, it will not mutex against
      bond state machine and incoming LACPDU which do not hold RTNL,
      So I add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup it.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bca44a73
    • D
      bonding: protect port for bond_3ad_adapter_speed_changed() · 71a06c59
      dingtianhong 提交于
      Jay Vosburgh said that the bond_3ad_adapter_speed_changed is
      called with RTNL only, and the function will modify the port's
      information with no further locking, it will not mutex against
      bond state machine and incoming LACPDU which do not hold RTNL,
      So I add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comment in the function is very old, cleanup it.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71a06c59
  12. 14 12月, 2013 1 次提交
    • D
      bonding: add RCU for bond_3ad_state_machine_handler() · be79bd04
      dingtianhong 提交于
      The bond_3ad_state_machine_handler() use the bond lock to protect
      the bond slave list and slave port together, but it is not enough,
      the bond slave list was link and unlink in RTNL, not bond lock,
      so I add RCU to protect the slave list from leaving.
      
      The bond lock is still used here, because when the slave has been
      removed from the list by the time the state machine runs, it appears
      to be possible for both function to manupulate the same aggregator->lag_ports
      by finding the aggregator via two different ports that are both members of
      that aggregator (i.e., port A of the agg is being unbound, and port B
      of the agg is runing its state machine).
      
      If I remove the bond lock, there are nothing to mutex changes
      to aggregator->lag_ports between bond_3ad_state_machine_handler and
      bond_3ad_unbind_slave, So the bond lock is the simplest way to protect
      aggregator->lag_ports.
      
      There was a lot of function need RCU protect, I have two choice
      to make the function in RCU-safe, (1) create new similar functions
      and make the bond slave list in RCU. (2) modify the existed functions
      and make them in read-side critical section, because the RCU
      read-side critical sections may be nested.
      
      I choose (2) because it is no need to create more similar functions.
      
      The nots in the function is still too old, clean up the nots.
      Suggested-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Suggested-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be79bd04
  13. 28 10月, 2013 2 次提交
  14. 18 10月, 2013 1 次提交
  15. 04 10月, 2013 1 次提交
    • N
      bonding: modify the old and add new xmit hash policies · 32819dc1
      Nikolay Aleksandrov 提交于
      This patch adds two new hash policy modes which use skb_flow_dissect:
      3 - Encapsulated layer 2+3
      4 - Encapsulated layer 3+4
      There should be a good improvement for tunnel users in those modes.
      It also changes the old hash functions to:
      hash ^= (__force u32)flow.dst ^ (__force u32)flow.src;
      hash ^= (hash >> 16);
      hash ^= (hash >> 8);
      
      Where hash will be initialized either to L2 hash, that is
      SRCMAC[5] XOR DSTMAC[5], or to flow->ports which should be extracted
      from the upper layer. Flow's dst and src are also extracted based on the
      xmit policy either directly from the buffer or by using skb_flow_dissect,
      but in both cases if the protocol is IPv6 then dst and src are obtained by
      ipv6_addr_hash() on the real addresses. In case of a non-dissectable
      packet, the algorithms fall back to L2 hashing.
      The bond_set_mode_ops() function is now obsolete and thus deleted
      because it was used only to set the proper hash policy. Also we trim a
      pointer from struct bonding because we no longer need to keep the hash
      function, now there's only a single hash function - bond_xmit_hash that
      works based on bond->params.xmit_policy.
      
      The hash function and skb_flow_dissect were suggested by Eric Dumazet.
      The layer names were suggested by Andy Gospodarek, because I suck at
      semantics.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32819dc1
  16. 29 9月, 2013 8 次提交
  17. 27 9月, 2013 3 次提交
  18. 04 9月, 2013 1 次提交
  19. 02 8月, 2013 1 次提交
    • N
      bonding: initial RCU conversion · 278b2083
      nikolay@redhat.com 提交于
      This patch does the initial bonding conversion to RCU. After it the
      following modes are protected by RCU alone: roundrobin, active-backup,
      broadcast and xor. Modes ALB/TLB and 3ad still acquire bond->lock for
      reading, and will be dealt with later. curr_active_slave needs to be
      dereferenced via rcu in the converted modes because the only thing
      protecting the slave after this patch is rcu_read_lock, so we need the
      proper barrier for weakly ordered archs and to make sure we don't have
      stale pointer. It's not tagged with __rcu yet because there's still work
      to be done to remove the curr_slave_lock, so sparse will complain when
      rcu_assign_pointer and rcu_dereference are used, but the alternative to use
      rcu_dereference_protected would've created much bigger code churn which is
      more difficult to test and review. That will be converted in time.
      
      1. Active-backup mode
       1.1 Perf recording while doing iperf -P 4
        - old bonding: iperf spent 0.55% in bonding, system spent 0.29% CPU
                       in bonding
        - new bonding: iperf spent 0.29% in bonding, system spent 0.15% CPU
                       in bonding
       1.2. Bandwidth measurements
        - old bonding: 16.1 gbps consistently
        - new bonding: 17.5 gbps consistently
      
      2. Round-robin mode
       2.1 Perf recording while doing iperf -P 4
        - old bonding: iperf spent 0.51% in bonding, system spent 0.24% CPU
                       in bonding
        - new bonding: iperf spent 0.16% in bonding, system spent 0.11% CPU
                       in bonding
       2.2 Bandwidth measurements
        - old bonding: 8 gbps (variable due to packet reorderings)
        - new bonding: 10 gbps (variable due to packet reorderings)
      
      Of course the latency has improved in all converted modes, and moreover
      while
      doing enslave/release (since it doesn't affect tx anymore).
      
      Also I've stress tested all modes doing enslave/release in a loop while
      transmitting traffic.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      278b2083