From: Jay Vosburgh <fubar@us.ibm.com>
To: Nikolay Aleksandrov <nikolay@redhat.com>
Cc: netdev@vger.kernel.org, andy@greyhouse.net, davem@davemloft.net
Subject: Re: [PATCH 1/5] bonding: mc addresses don't get deleted on enslave failure
Date: Thu, 18 Apr 2013 09:58:00 -0700 [thread overview]
Message-ID: <14509.1366304280@death.nxdomain> (raw)
In-Reply-To: <1366295697-31037-2-git-send-email-nikolay@redhat.com>
Nikolay Aleksandrov <nikolay@redhat.com> wrote:
>Add dev_mc_del after err_detach as that's the first error path
>after they're added. The main issue is the mc addresses' refcount
>which only gets bumped up.
>
>Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
All 5 of these patches look good to me. The only minor nits are
that the above description says "dev_mc_del," but the actual function
call added is bond_mc_list_flush (which in turn does call dev_mc_dev),
and that this patch (#1) modifies the lacpdu_multicast variable
initialization, which isn't really necessary for the bug fix.
-J
>---
> drivers/net/bonding/bond_main.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index a61a760..dc0153b 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1523,6 +1523,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> struct sockaddr addr;
> int link_reporting;
> int res = 0;
>+ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR;
>
> if (!bond->params.use_carrier &&
> slave_dev->ethtool_ops->get_link == NULL &&
>@@ -1726,12 +1727,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> netif_addr_unlock_bh(bond_dev);
> }
>
>- if (bond->params.mode == BOND_MODE_8023AD) {
>+ if (bond->params.mode == BOND_MODE_8023AD)
> /* add lacpdu mc addr to mc list */
>- u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR;
>-
> dev_mc_add(slave_dev, lacpdu_multicast);
>- }
>
> bond_add_vlans_on_slave(bond, slave_dev);
>
>@@ -1901,6 +1899,11 @@ err_dest_symlinks:
> bond_destroy_slave_symlinks(bond_dev, slave_dev);
>
> err_detach:
>+ if (!USES_PRIMARY(bond->params.mode)) {
>+ netif_addr_lock_bh(bond_dev);
>+ bond_mc_list_flush(bond_dev, slave_dev);
>+ netif_addr_unlock_bh(bond_dev);
>+ }
> write_lock_bh(&bond->lock);
> bond_detach_slave(bond, new_slave);
> write_unlock_bh(&bond->lock);
>--
>1.8.1.4
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
next prev parent reply other threads:[~2013-04-18 16:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 14:34 [PATCH 0/5] bonding: enslave and locking bug fixes Nikolay Aleksandrov
2013-04-18 14:34 ` [PATCH 1/5] bonding: mc addresses don't get deleted on enslave failure Nikolay Aleksandrov
2013-04-18 16:58 ` Jay Vosburgh [this message]
2013-04-18 17:15 ` Nikolay Aleksandrov
2013-04-18 14:34 ` [PATCH 2/5] bonding: vlans " Nikolay Aleksandrov
2013-04-18 14:34 ` [PATCH 3/5] bonding: primary_slave & curr_active_slave are not cleaned " Nikolay Aleksandrov
2013-04-18 14:34 ` [PATCH 4/5] bonding: disable netpoll " Nikolay Aleksandrov
2013-04-18 14:34 ` [PATCH 5/5] bonding: in bond_mc_swap() bond's mc addr list is walked without lock Nikolay Aleksandrov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14509.1366304280@death.nxdomain \
--to=fubar@us.ibm.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nikolay@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.