• Jay Vosburgh's avatar
    bonding: don't use stale speed and duplex information · 266b495f
    Jay Vosburgh authored
    There is presently a race condition between the bonding periodic
    link monitor and the updating of a slave's speed and duplex.  The former
    occurs on a periodic basis, and the latter in response to a driver's
    calling of netif_carrier_on.
    
    	It is possible for the periodic monitor to run between the
    driver call of netif_carrier_on and the receipt of the NETDEV_CHANGE
    event that causes bonding to update the slave's speed and duplex.  This
    manifests most notably as a report that a slave is up and "0 Mbps full
    duplex" after enslavement, but in principle could report an incorrect
    speed and duplex after any link up event if the device comes up with a
    different speed or duplex.  This affects the 802.3ad aggregator
    selection, as the speed and duplex are selection criteria.
    
    	This is fixed by updating the speed and duplex in the periodic
    monitor, prior to using that information.
    
    	This was done historically in bonding, but the call to
    bond_update_speed_duplex was removed in commit 876254ae ("bonding:
    don't call update_speed_duplex() under spinlocks"), as it might sleep
    under lock.  Later, the locking was changed to only hold RTNL, and so
    after commit 876254ae ("bonding: don't call update_speed_duplex()
    under spinlocks") this call is again safe.
    Tested-by: default avatar"Tantilov, Emil S" <emil.s.tantilov@intel.com>
    Cc: Veaceslav Falico <vfalico@gmail.com>
    Cc: dingtianhong <dingtianhong@huawei.com>
    Fixes: 876254ae ("bonding: don't call update_speed_duplex() under spinlocks")
    Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
    Acked-by: default avatarDing Tianhong <dingtianhong@huawei.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    266b495f
bond_main.c 133 KB