1. 20 Feb, 2014 1 commit
  2. 19 Feb, 2014 1 commit
  3. 18 Feb, 2014 9 commits
  4. 17 Feb, 2014 4 commits
  5. 13 Feb, 2014 2 commits
  6. 11 Feb, 2014 1 commit
  7. 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
  8. 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
  9. 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
  10. 23 Jan, 2014 2 commits
  11. 22 Jan, 2014 13 commits
  12. 18 Jan, 2014 2 commits