Subject: Re: [PATCH net v3 03/11] bonding: fix unexpected IFF_BONDING bit unset

From: Jay Vosburgh <[email-masked]>
Date: Mon, 16 Sep 2019 17:03:55 +0200

Jiri Pirko <[email-masked]> wrote:

>Mon, Sep 16, 2019 at 03:47:54PM CEST, [email-masked] wrote:
>>The IFF_BONDING means bonding master or bonding slave device.
>>->ndo_add_slave() sets IFF_BONDING flag and ->ndo_del_slave() unsets
>>IFF_BONDING flag.
>>
>>bond0<--bond1
>>
>>Both bond0 and bond1 are bonding device and these should keep having
>>IFF_BONDING flag until they are removed.
>>But bond1 would lose IFF_BONDING at ->ndo_del_slave() because that routine
>>do not check whether the slave device is the bonding type or not.
>>This patch adds the interface type check routine before removing
>>IFF_BONDING flag.
>>
>>Test commands:
>>    ip link add bond0 type bond
>>    ip link add bond1 type bond
>>    ip link set bond1 master bond0
>>    ip link set bond1 nomaster
>>    ip link del bond1 type bond
>>    ip link add bond1 type bond
>
>Interesting. I wonder why bond-in-bond is not forbidden...

	I think mostly because nesting wasn't originally forbidden, and
there are apparently users of it out in the wild, judging from the
number of times I see configurations or queries about an active-backup
bond with two 802.3ad bonding slaves.  That particular configuration
doesn't have any advantage (802.3ad will internally manage that
situation), but I don't see that we can now forbid nesting bonds without
potentially breaking existing user space configurations.

	-J

---
	-Jay Vosburgh, [email-masked]