1. 18 6月, 2013 1 次提交
  2. 13 6月, 2013 2 次提交
    • N
      bonding: fix igmp_retrans type and two related races · 4f5474e7
      Nikolay Aleksandrov 提交于
      First the type of igmp_retrans (which is the actual counter of
      igmp_resend parameter) is changed to u8 to be able to store values up
      to 255 (as per documentation). There are two races that were hidden
      there and which are easy to trigger after the previous fix, the first is
      between bond_resend_igmp_join_requests and bond_change_active_slave
      where igmp_retrans is set and can be altered by the periodic. The second
      race condition is between multiple running instances of the periodic
      (upon execution it can be scheduled again for immediate execution which
      can cause the counter to go < 0 which in the unsigned case leads to
      unnecessary igmp retransmissions).
      Since in bond_change_active_slave bond->lock is held for reading and
      curr_slave_lock for writing, we use curr_slave_lock for mutual
      exclusion. We can't drop them as there're cases where RTNL is not held
      when bond_change_active_slave is called. RCU is unlocked in
      bond_resend_igmp_join_requests before getting curr_slave_lock since we
      don't need it there and it's pointless to delay.
      The decrement is moved inside the "if" block because if we decrement
      unconditionally there's still a possibility for a race condition although
      it is much more difficult to hit (many changes have to happen in
      a very short period in order to trigger) which in the case of 3 parallel
      running instances of this function and igmp_retrans == 1
      (with check bond->igmp_retrans-- > 1) is:
      f1 passes, doesn't re-schedule, but decrements - igmp_retrans = 0
      f2 then passes, doesn't re-schedule, but decrements - igmp_retrans = 255
      f3 does the unnecessary retransmissions.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f5474e7
    • N
      bonding: reset master mac on first enslave failure · b8fad459
      Nikolay Aleksandrov 提交于
      If the bond device is supposed to get the first slave's MAC address and
      the first enslavement fails then we need to reset the master's MAC
      otherwise it will stay the same as the failed slave device. We do it
      after err_undo_flags since that is the first place where the MAC can be
      changed and we check if it should've been the first slave and if the
      bond's MAC was set to it because that err place is used by multiple
      locations prior to changing the master's MAC address.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8fad459
  3. 08 6月, 2013 2 次提交
    • J
      bonding: disallow change of MAC if fail_over_mac enabled · 1b5acd29
      Jay Vosburgh 提交于
      Currently, if fail_over_mac is set to active, then attempts to
      change the MAC of the bond itself silently fail.  However, if fail_over_mac
      is set to follow, changes are permitted.
      
      	Permitting the bond's MAC to change with fail_over_mac=follow
      will disrupt the follow functionality, which normally controls the
      assignment of MAC address to the bond and its slaves, and can cause
      multiple ports to be assigned the same MAC address. which will interfere
      with the functioning of the device (where the device here is a
      virtualization-aware card for s390, qeth).
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b5acd29
    • J
      bonding: Convert hw addr handling to sync/unsync, support ucast addresses · 303d1cbf
      Jay Vosburgh 提交于
      This patch converts bonding to use the dev_uc/mc_sync and
      dev_uc/mc_sync_multiple functions for updating the hardware addresses
      of bonding slaves.
      
      	The existing functions to add or remove addresses are removed,
      and their functionality is replaced with calls to dev_mc_sync or
      dev_mc_sync_multiple, depending upon the bonding mode.
      
      	Calls to dev_uc_sync and dev_uc_sync_multiple are also added,
      so that unicast addresses added to a bond will be properly synced with
      its slaves.
      
      	Various functions are renamed to better reflect the new
      situation, and relevant comments are updated.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Cc: Vlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      303d1cbf
  4. 29 5月, 2013 3 次提交
  5. 28 5月, 2013 1 次提交
  6. 20 5月, 2013 4 次提交
  7. 17 5月, 2013 1 次提交
    • E
      bonding: allow TSO being set on bonding master · b0ce3508
      Eric Dumazet 提交于
      In some situations, we need to disable TSO on bonding slaves.
      
      bonding device automatically unset TSO in bond_fix_features(), and
      performance is not good because :
      
      1) We consume more cpu cycles.
      
      2) GSO segmentation has some bugs leading to out of order TCP packets
      if this segmentation is done before virtual device. This particular
      problem will be addressed in a separate patch.
      
      This patch allows TSO being set/unset on the bonding master,
      so that GSO segmentation is done after bonding layer.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Michał Mirosław <mirqus@gmail.com>
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0ce3508
  8. 25 4月, 2013 1 次提交
  9. 20 4月, 2013 10 次提交
  10. 19 4月, 2013 1 次提交
  11. 12 4月, 2013 2 次提交
  12. 10 4月, 2013 1 次提交
    • A
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro 提交于
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      layout.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d9dda78b
  13. 09 4月, 2013 2 次提交
  14. 05 4月, 2013 1 次提交
    • V
      bonding: remove sysfs before removing devices · 4de79c73
      Veaceslav Falico 提交于
      We have a race condition if we try to rmmod bonding and simultaneously add
      a bond master through sysfs. In bonding_exit() we first remove the devices
      (through rtnl_link_unregister() ) and only after that we remove the sysfs.
      If we manage to add a device through sysfs after that the devices were
      removed - we'll end up with that device/sysfs structure and with the module
      unloaded.
      
      Fix this by first removing the sysfs and only after that calling
      rtnl_link_unregister().
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4de79c73
  15. 03 4月, 2013 1 次提交
  16. 30 3月, 2013 1 次提交
  17. 27 3月, 2013 2 次提交
  18. 13 3月, 2013 1 次提交
    • V
      bonding: don't call update_speed_duplex() under spinlocks · 876254ae
      Veaceslav Falico 提交于
      bond_update_speed_duplex() might sleep while calling underlying slave's
      routines. Move it out of atomic context in bond_enslave() and remove it
      from bond_miimon_commit() - it was introduced by commit 546add79, however
      when the slave interfaces go up/change state it's their responsibility to
      fire NETDEV_UP/NETDEV_CHANGE events so that bonding can properly update
      their speed.
      
      I've tested it on all combinations of ifup/ifdown, autoneg/speed/duplex
      changes, remote-controlled and local, on (not) MII-based cards. All changes
      are visible.
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      876254ae
  19. 08 3月, 2013 1 次提交
  20. 27 2月, 2013 1 次提交
  21. 19 2月, 2013 1 次提交