From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Jiri Bohac <jbohac@suse.cz>
Cc: Jay Vosburgh <fubar@us.ibm.com>,
"bonding-devel@lists.sourceforge.net"
<bonding-devel@lists.sourceforge.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Bonding on bond
Date: Wed, 19 Jan 2011 21:33:19 +0100 [thread overview]
Message-ID: <4D374A8F.2020303@gmail.com> (raw)
Le 19/01/2011 16:49, Jiri Bohac a écrit :
> On Tue, Jan 18, 2011 at 09:07:20AM +0100, Nicolas de Pesloüan wrote:
>> Staking bond is not supported. Currently, no setup is know to
>> require stacking bond.
> I agree. This question and weird bugreports from people trying
> this come up over and over. How about this patch?
Why not. Adding this to the documentation should also help.
> bonding: prohibit enslaving of bonding masters
>
> Nested bonding is not supported and will result in strange problems, e.g.:
> - netif_receive_skb() will not properly change skb->dev to point to the
> uppoer-most bonding master
> - arp monitor will not work (dev->last_rx is only updated by hardware drivers)
> - accidentally enslaving a bonding master to itself will cause an infinite
> recursion in the TX path
>
> This patch prevents this by prohibiting a bonding master from being further enslaved.
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index b1025b8..d4d5f42 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1448,8 +1448,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> }
>
> /* already enslaved */
> - if (slave_dev->flags & IFF_SLAVE) {
> - pr_debug("Error, Device was already enslaved\n");
> + if (slave_dev->priv_flags & IFF_BONDING) {
> + pr_debug("Error, Device already enslaved or a bonding master\n");
Even if it is possible to test for slave and for master with a single condition (IFF_BONDING), I
suggest to split the tests and the error messages, to give end user the best possible diagnostic.
If the device is already a master, let's say it.
If the device is already enslaved, let's continue to say it. It might even be better to give the
name of the other master that already own this slave.
> return -EBUSY;
> }
>
>
>
> --
> Jiri Bohac <jbohac@suse.cz>
> SUSE Labs, SUSE CZ
next reply other threads:[~2011-01-19 20:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 20:33 Nicolas de Pesloüan [this message]
2011-01-20 15:31 ` Bonding on bond Jiri Bohac
2011-01-20 16:12 ` Nicolas de Pesloüan
2011-01-20 19:53 ` Jay Vosburgh
2011-01-22 22:57 ` Nicolas de Pesloüan
2011-01-29 0:38 ` Jay Vosburgh
2011-02-02 10:19 ` Nicolas de Pesloüan
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=4D374A8F.2020303@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=bonding-devel@lists.sourceforge.net \
--cc=fubar@us.ibm.com \
--cc=jbohac@suse.cz \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).