Up until 00503b6f702e (part of 3.14-rc1), the bonding driver could be
used to enslave tun-interfaces. 00503b6f702e broke that behaviour,
afaics as an unintended side-effect.
For the purpose of bond-over-tun in balance-rr mode, simply ignoring the
error from dev_set_mac_address() is good enough. I am not familiar
enough with the code to judge what new problems this patch might
introduce.
Signed-off-by: Joern Engel <jo...@purestorage.com>
---
drivers/net/bonding/bond_main.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 1f276fa30ba6..bc5dba847f50 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1489,11 +1489,7 @@ int bond_enslave(struct net_device *bond_dev, struct
net_device *slave_dev)
*/
memcpy(addr.sa_data, bond_dev->dev_addr, bond_dev->addr_len);
addr.sa_family = slave_dev->type;
- res = dev_set_mac_address(slave_dev, &addr);
- if (res) {
- netdev_dbg(bond_dev, "Error %d calling
set_mac_address\n", res);
- goto err_restore_mtu;
- }
+ dev_set_mac_address(slave_dev, &addr);
}
/* set slave flag before open to prevent IPv6 addrconf */
@@ -1777,7 +1773,6 @@ err_restore_mac:
dev_set_mac_address(slave_dev, &addr);
}
-err_restore_mtu:
dev_set_mtu(slave_dev, new_slave->original_mtu);
err_free:
--
2.1.4
