ACK: [E][F][SRU][PATCH 1/1] bonding: fix state transition issue in link monitoring
Andrea Righi
andrea.righi at canonical.com
Thu Nov 28 12:30:15 UTC 2019
On Wed, Nov 13, 2019 at 03:33:23PM +0800, Po-Hsu Lin wrote:
> From: Jay Vosburgh <jay.vosburgh at canonical.com>
>
> BugLink: https://bugs.launchpad.net/bugs/1852077
>
> Since de77ecd4ef02 ("bonding: improve link-status update in
> mii-monitoring"), the bonding driver has utilized two separate variables
> to indicate the next link state a particular slave should transition to.
> Each is used to communicate to a different portion of the link state
> change commit logic; one to the bond_miimon_commit function itself, and
> another to the state transition logic.
>
> Unfortunately, the two variables can become unsynchronized,
> resulting in incorrect link state transitions within bonding. This can
> cause slaves to become stuck in an incorrect link state until a
> subsequent carrier state transition.
>
> The issue occurs when a special case in bond_slave_netdev_event
> sets slave->link directly to BOND_LINK_FAIL. On the next pass through
> bond_miimon_inspect after the slave goes carrier up, the BOND_LINK_FAIL
> case will set the proposed next state (link_new_state) to BOND_LINK_UP,
> but the new_link to BOND_LINK_DOWN. The setting of the final link state
> from new_link comes after that from link_new_state, and so the slave
> will end up incorrectly in _DOWN state.
>
> Resolve this by combining the two variables into one.
>
> Reported-by: Aleksei Zakharov <zakharov.a.g at yandex.ru>
> Reported-by: Sha Zhang <zhangsha.zhang at huawei.com>
> Cc: Mahesh Bandewar <maheshb at google.com>
> Fixes: de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring")
> Signed-off-by: Jay Vosburgh <jay.vosburgh at canonical.com>
> Signed-off-by: David S. Miller <davem at davemloft.net>
> (cherry picked from commit 1899bb325149e481de31a4f32b59ea6f24e176ea)
> Signed-off-by: Po-Hsu Lin <po-hsu.lin at canonical.com>
> ---
Acked-by: Andrea Righi <andrea.righi at canonical.com>
More information about the kernel-team
mailing list