Message ID | 1333383430-17456-2-git-send-email-ogerlitz@mellanox.com |
---|---|
State | Superseded, archived |
Delegated to: | David Miller |
Headers | show |
Or Gerlitz <ogerlitz@mellanox.com> wrote: >From: Shlomo Pongratz <shlomop@mellanox.com> > >commit 7d26bb103c4 "bonding: emit event when bonding changes MAC" didn't >take care to emit the NETDEV_CHANGEADDR event in other places where bonding >actually changes the mac address (to all zeroes), in bond_release, and >bond_release_all. As a result the neighbours aren't deleted by the core >networking code (which does so upon getting that event). >Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com> Is the bond_release_all notifier call actually necessary in your testing? The bond itself is destroyed immediately after bond_release_all returns, so I would expect the neighbours to be deleted then. For that path we probably don't need to zero the mac at all (or compute features, for that matter). -J >--- > drivers/net/bonding/bond_main.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > >diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c >index a20b585..b0a278d 100644 >--- a/drivers/net/bonding/bond_main.c >+++ b/drivers/net/bonding/bond_main.c >@@ -2035,6 +2035,9 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev) > write_unlock_bh(&bond->lock); > unblock_netpoll_tx(); > >+ if (bond->slave_cnt == 0) >+ call_netdevice_notifiers(NETDEV_CHANGEADDR, bond->dev); >+ > bond_compute_features(bond); > if (!(bond_dev->features & NETIF_F_VLAN_CHALLENGED) && > (old_features & NETIF_F_VLAN_CHALLENGED)) >@@ -2218,6 +2221,8 @@ static int bond_release_all(struct net_device *bond_dev) > out: > write_unlock_bh(&bond->lock); > >+ call_netdevice_notifiers(NETDEV_CHANGEADDR, bond->dev); >+ > bond_compute_features(bond); > > return 0; >-- >1.7.1 --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4/4/2012 1:28 AM, Jay Vosburgh wrote: > Is the bond_release_all notifier call actually necessary in your > testing? The bond itself is destroyed immediately after > bond_release_all returns, so I would expect the neighbours to be > deleted then. For that path we probably don't need to zero the mac at > all (or compute features, for that matter). yep, you're right, will remove this extra emitting of event and resend, thanks. Or. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index a20b585..b0a278d 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -2035,6 +2035,9 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev) write_unlock_bh(&bond->lock); unblock_netpoll_tx(); + if (bond->slave_cnt == 0) + call_netdevice_notifiers(NETDEV_CHANGEADDR, bond->dev); + bond_compute_features(bond); if (!(bond_dev->features & NETIF_F_VLAN_CHALLENGED) && (old_features & NETIF_F_VLAN_CHALLENGED)) @@ -2218,6 +2221,8 @@ static int bond_release_all(struct net_device *bond_dev) out: write_unlock_bh(&bond->lock); + call_netdevice_notifiers(NETDEV_CHANGEADDR, bond->dev); + bond_compute_features(bond); return 0;