1. 13 Feb, 2014 1 commit
    • dingtianhong's avatar
      bonding: Fix deadlock in bonding driver when using netpoll · f80889a5
      dingtianhong authored
      
      
      The bonding driver take write locks and spin locks that are shared
      by the tx path in enslave processing and notification processing,
      If the netconsole is in use, the bonding can call printk which puts
      us in the netpoll tx path, if the netconsole is attached to the bonding
      driver, result in deadlock.
      
      So add protection for these place, by checking the netpoll_block_tx
      state, we can defer the sending of the netconsole frames until a later
      time using the retransmit feature of netpoll_send_skb that is triggered
      on the return code NETDEV_TX_BUSY.
      
      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>
      f80889a5
  2. 11 Feb, 2014 1 commit
  3. 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
  4. 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
  5. 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
  6. 23 Jan, 2014 2 commits
  7. 22 Jan, 2014 13 commits
  8. 18 Jan, 2014 2 commits
  9. 17 Jan, 2014 1 commit
  10. 15 Jan, 2014 1 commit
  11. 10 Jan, 2014 1 commit
    • Jason Wang's avatar
      net: core: explicitly select a txq before doing l2 forwarding · f663dd9a
      Jason Wang authored
      
      
      Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
      will cause several issues:
      
      - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
        instead of lower device which misses the necessary txq synchronization for
        lower device such as txq stopping or frozen required by dev watchdog or
        control path.
      - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
        watchdog.
      - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
        when tso is disabled for lower device.
      
      Fix this by explicitly introducing a new param for .ndo_select_queue() for just
      selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
      extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
      forwarding transmission.
      
      With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
      to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
      a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
      dev_queue_xmit() to do the transmission.
      
      In the future, it was also required for macvtap l2 forwarding support since it
      provides a necessary synchronization method.
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f663dd9a
  12. 04 Jan, 2014 1 commit
  13. 02 Jan, 2014 4 commits
  14. 31 Dec, 2013 2 commits
  15. 29 Dec, 2013 1 commit
  16. 14 Dec, 2013 5 commits