On 2022-09-02 11:28 -0700, Jay Vosburgh wrote:
Benjamin Poirier bpoirier@nvidia.com wrote:
Repeating a couple of questions that I suspect were missed the first time around:
Thanks for repeating, I did miss the other questions, sorry.
[...]
@@ -2171,12 +2169,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, dev_uc_sync_multiple(slave_dev, bond_dev); netif_addr_unlock_bh(bond_dev);
if (BOND_MODE(bond) == BOND_MODE_8023AD) {/* add lacpdu mc addr to mc list */u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR;
if (BOND_MODE(bond) == BOND_MODE_8023AD) dev_mc_add(slave_dev, lacpdu_multicast);
}Just to make sure I'm clear (not missing something in the churn), the above changes regarding lacpdu_multicast have no functional impact, correct? They appear to move lacpdu_multicast to global scope for use in the change just below.
Yes, that's right - no functional impact. I'll split that to a separate patch to make it clearer.
bond->slave_cnt++; @@ -4211,6 +4205,9 @@ static int bond_open(struct net_device *bond_dev) /* register to receive LACPDUs */ bond->recv_probe = bond_3ad_lacpdu_recv; bond_3ad_initiate_agg_selection(bond, 1);
bond_for_each_slave(bond, slave, iter)dev_mc_add(slave->dev, lacpdu_multicast);After this change, am I understanding correctly that both bond_enslave() and bond_open() will call dev_mc_add() for lacpdu_multicast? Since dev_mc_add() -> __dev_mc_add() calls __hw_addr_add_ex() with sync=false and exclusive=false, could that allow us to end up with two references for lacpdu_multicast?
You are correct once again. When enslaving to an up bond (case in the selftest), it is ok, but when enslaving to a down bond and then setting it up, there is a double add.
Thanks for the review. I'll send a v3.