1. 26 Mar, 2014 4 commits
    • dingtianhong's avatar
      bonding: add net_ratelimt to avoid spam in arp interval · 4873ac3c
      dingtianhong authored
      
      
      Remove the unnecessary log and add net_ratelimit to the others, in order to
      avoid spam the log.
      
      Cc: Joe Perches <joe@perches.com>
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Veaceslav Falico <vfalico@redhat.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4873ac3c
    • dingtianhong's avatar
      bonding: support QinQ for bond arp interval · fbd929f2
      dingtianhong authored
      
      
      The bond send arp request to indicate that the slave is active, and if the bond dev
      is a vlan dev, it will set the vlan tag in skb to notice the vlan group, but the
      bond could only send a skb with 802.1q proto, not support for QinQ.
      
      So add outer tag for lower vlan tag and inner tag for upper vlan tag to support QinQ,
      The new skb will be consist of two vlan tag just like this:
      
      dst mac | src mac | outer vlan tag | inner vlan tag | data | .....
      
      If We don't need QinQ, the inner vlan tag could be set to 0 and use outer vlan tag
       as a normal vlan group.
      
      Using "ip link" to configure the bond for QinQ and add test log:
      
      ip link add link bond0  bond0.20 type vlan proto 802.1ad id 20
      ip link add link bond0.20  bond0.20.200 type vlan proto 802.1q id 200
      
      ifconfig bond0.20 11.11.20.36/24
      ifconfig bond0.20.200 11.11.200.36/24
      
      echo +11.11.200.37 > /sys/class/net/bond0/bonding/arp_ip_target
      
      90:e2:ba:07:4a:5c (oui Unknown) > Broadcast, ethertype 802.1Q-QinQ (0x88a8),length 50: vlan 20, p 0,ethertype 802.1Q, vlan 200, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 11.11.200.37 tell 11.11.200.36, length 28
      
      90:e2:ba:06:f9:86 (oui Unknown) > 90:e2:ba:07:4a:5c (oui Unknown), ethertype 802.1Q-QinQ (0x88a8), length 50: vlan 20, p 0, ethertype 802.1Q, vlan 200, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reply 11.11.200.37 is-at 90:e2:ba:06:f9:86 (oui Unknown), length 28
      
      v1->v2: remove the comment "TODO: QinQ?".
      
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Veaceslav Falico <vfalico@redhat.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbd929f2
    • dingtianhong's avatar
      bonding: ratelimit pr_err() for bond xmit broadcast · 9152e26d
      dingtianhong authored
      
      
      It may spam if the system is out of the memory, add ratelimit for it.
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9152e26d
    • dingtianhong's avatar
      bonding: slight optimization for bond xmit path · 054bb880
      dingtianhong authored
      
      
      Add unlikely() micro to the unlikely conditions in the bond
      xmit path for slight optimization.
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      054bb880
  2. 12 Mar, 2014 1 commit
  3. 06 Mar, 2014 2 commits
  4. 02 Mar, 2014 1 commit
    • Veaceslav Falico's avatar
      bonding: send arp requests even if there's no route to them · 28572760
      Veaceslav Falico authored
      
      
      Currently we're only sending arp requests if we have a route to the target
      (and, thus, can find out the source ip address).
      
      There are some use cases, however, where we don't want/need to set an ip
      address (or set up a specific route) for bonding to use arp monitoring *for
      traffic generation*. We can easily send arp probes (arp requests with src
      ip == 0) to generate arp broadcast responses from the target ip and use
      them for determining if the target is up.
      
      This, obviously, won't work with arp validation - because we don't have the
      ip address set and, thus, will filter out the responses. So in that case -
      print a warning.
      
      CC: François CACHEREUL <f.cachereul@alphalink.fr>
      CC: Zhenjie Chen <zhchen@redhat.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28572760
  5. 27 Feb, 2014 1 commit
  6. 26 Feb, 2014 3 commits
    • Nikolay Aleksandrov's avatar
      bonding: fix a div error caused by the slave release path · ee6154e1
      Nikolay Aleksandrov authored
      There's a bug in the slave release function which leads the transmit
      functions which use the bond->slave_cnt to a div by 0 because we might
      just have released our last slave and made slave_cnt == 0 but at the same
      time we may have a transmitter after the check for an empty list which will
      fetch it and use it in the slave id calculation.
      Fix it by moving the slave_cnt after synchronize_rcu so if this was our
      last slave any new transmitters will see an empty slave list which is
      checked after rcu lock but before calling the mode transmit functions
      which rely on bond->slave_cnt.
      
      Fixes: 278b2083
      
       ("bonding: initial RCU conversion")
      
      CC: Veaceslav Falico <vfalico@redhat.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: default avatarVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee6154e1
    • dingtianhong's avatar
      bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for ab arp monitor · b0929915
      dingtianhong authored
      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: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0929915
    • dingtianhong's avatar
      bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for 802.3ad mode · 5e5b0665
      dingtianhong authored
      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: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e5b0665
  7. 24 Feb, 2014 2 commits
  8. 20 Feb, 2014 1 commit
  9. 19 Feb, 2014 1 commit
  10. 18 Feb, 2014 9 commits
  11. 17 Feb, 2014 4 commits
  12. 13 Feb, 2014 2 commits
  13. 11 Feb, 2014 1 commit
  14. 05 Feb, 2014 2 commits
    • dingtianhong's avatar
      bonding: fail_over_mac should only affect AB mode in bond_set_mac_address() · cc689aaa
      dingtianhong authored
      
      
      The fail_over_mac could be set to active or follow in any time for all modes,
      so if the fail_over_mac is not none and the current mode is not active-backup,
      the bond_set_mac_address() could not change the master and slave's MAC address.
      
      In bond_set_mac_address(), the fail_over_mac should only affect AB mode, so modify
      to check the mode in addition to fail_over_mac when setting bond's MAC address.
      
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Veaceslav Falico <vfalico@redhat.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc689aaa
    • dingtianhong's avatar
      bonding: fail_over_mac should only affect AB mode at enslave and removal processing · 00503b6f
      dingtianhong authored
      
      
      According to bonding.txt, the fail_over_ma should only affect active-backup mode,
      but I found that the fail_over_mac could be set to active or follow in all
      modes, this will cause new slave could not be set to bond's MAC address at
      enslave processing and restore its own MAC address at removal processing.
      
      The correct way to fix the problem is that we should not add restrictions when
      setting options, just need to modify the bond enslave and removal processing
      to check the mode in addition to fail_over_mac when setting a slave's MAC during
      enslavement. The change active slave processing already only calls the fail_over_mac
      function when in active-backup mode.
      
      Thanks for Jay's suggestion.
      
      The patch also modify the pr_warning() to pr_warn().
      
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Veaceslav Falico <vfalico@redhat.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      00503b6f
  15. 29 Jan, 2014 1 commit
    • Ding Tianhong's avatar
      bonding: fix locking in bond_loadbalance_arp_mon() · 6fde8f03
      Ding Tianhong authored
      The commit 1d3ee88a
      
      
      (bonding: add netlink attributes to slave link dev)
      has add rtmsg_ifinfo() in bond_set_active_slave() and
      bond_set_backup_slave(), so the two function need to
      called in RTNL lock, but bond_loadbalance_arp_mon()
      only calling these functions in RCU, warning message
      will occurs.
      
      fix this by add a new function bond_slave_state_change(),
      which will reset the slave's state after slave link check,
      so remove the bond_set_xxx_slave() from the cycle and only
      record the slave_state_changed, this will call the new
      function to set all slaves to new state in RTNL later.
      
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Veaceslav Falico <vfalico@redhat.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6fde8f03
  16. 27 Jan, 2014 2 commits
    • Veaceslav Falico's avatar
      bonding: restructure locking of bond_ab_arp_probe() · f2ebd477
      Veaceslav Falico authored
      
      
      Currently we're calling it from under RCU context, however we're using some
      functions that require rtnl to be held.
      
      Fix this by restructuring the locking - don't call it under any locks,
      aquire rcu_read_lock() if we're sending _only_ (i.e. we have the active
      slave present), and use rtnl locking otherwise - if we need to modify
      (in)active flags of a slave.
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2ebd477
    • Veaceslav Falico's avatar
      bonding: RCUify bond_ab_arp_probe · 98b90f26
      Veaceslav Falico authored
      
      
      Currently bond_ab_arp_probe() is always called under rcu_read_lock(),
      however to work with curr_active_slave we're still holding the
      curr_slave_lock.
      
      To remove that curr_slave_lock - rcu_dereference the bond's
      curr_active_slave and use it further - so that we're sure the slave won't
      go away, and we don't care if it will change in the meanwhile.
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98b90f26
  17. 23 Jan, 2014 2 commits
  18. 22 Jan, 2014 1 commit