bonding: fix panic on non-ARPHRD_ETHER enslave failure
Subsystems (3)
PATCH 1/1 bonding: fix panic on non-ARPHRD_ETHER enslave failure
Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
are not ARPHRD_ETHER, if needed, it resets the bonding device back to ARPHRD_ETHER by calling ether_setup.
Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
if the bond device is up, leaving it in a quasi-down state without having actually gone through dev_close. For bonding, if any periodic work queue items are active (miimon, arp_interval, etc), those will remain running, as they are stopped by bond_close. At this point, if the bonding module is unloaded or the bond is deleted, the system will panic when the work function is called.
This panic is resolved by calling dev_close on the bond itself
prior to calling ether_setup.
--- drivers/net/bonding/bond_main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/bonding/bond_main.c +1 -0
@@ -1749,6 +1749,7 @@ err_undo_flags: slave_dev->dev_addr))eth_hw_addr_random (bond_dev);if (bond_dev->type !=ARPHRD_ETHER ) { +dev_close (bond_dev);ether_setup (bond_dev); bond_dev->flags |=IFF_MASTER ; bond_dev->priv_flags &= ~IFF_TX_SKB_SHARING ;
Signature · 1 line
1.9.1
Quoted 29 lines · Jay Vosburgh
Since commit
7d5cd2ce529b, whenbond_enslavefails on devices that
are notARPHRD_ETHER, if needed, it resets the bonding device back toARPHRD_ETHERby callingether_setup.Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UPif the bond device is up, leaving it in a quasi-down state without having actually gone through
dev_close. For bonding, if any periodic work queue items are active (miimon,arp_interval, etc), those will remain running, as they are stopped bybond_close. At this point, if the bonding module is unloaded or the bond is deleted, the system will panic when the work function is called.This panic is resolved by calling
dev_closeon the bond itself
prior to callingether_setup.Cc Nikolay Aleksandrov <[email protected]>Signed-off-by Jay Vosburgh <[email protected]>Fixes 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")--- drivers/net/bonding/bond_main.c | 1 + 1 file changed, 1 insertion(+)drivers/net/bonding/bond_main.c +0
-0
drivers/net/bonding/bond_main.c err_undo_flags: · line 1755
Quoted 7 lines
drivers/net/bonding/bond_main.c +1
-0@@ -1749,6 +1749,7 @@ err_undo_flags: slave_dev->dev_addr))eth_hw_addr_random (bond_dev);if (bond_dev->type !=ARPHRD_ETHER ) { +dev_close (bond_dev);ether_setup (bond_dev); bond_dev->flags |=IFF_MASTER ; bond_dev->priv_flags &= ~IFF_TX_SKB_SHARING ;
Oh, I've missed it. Very good catch!
Thanks,
Nik
David Miller
maintainerFrom: Jay Vosburgh <[email protected]>
Date: Fri, 06 Nov 2015 17:23:23 -0800
Quoted 13 lines
Since commit
7d5cd2ce529b, whenbond_enslavefails on devices that
are notARPHRD_ETHER, if needed, it resets the bonding device back toARPHRD_ETHERby callingether_setup.Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UPif the bond device is up, leaving it in a quasi-down state without having actually gone through
dev_close. For bonding, if any periodic work queue items are active (miimon,arp_interval, etc), those will remain running, as they are stopped bybond_close. At this point, if the bonding module is unloaded or the bond is deleted, the system will panic when the work function is called.
Quoted 6 lines
This panic is resolved by calling
dev_closeon the bond itself
prior to callingether_setup.Cc Nikolay Aleksandrov <[email protected]>Signed-off-by Jay Vosburgh <[email protected]>Fixes 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")
Applied and queued up for -stable, thanks.