Jiri Pirko <j...@resnulli.us> wrote:

>Mon, Sep 16, 2019 at 03:47:54PM CEST, ap420...@gmail.com 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, jay.vosbu...@canonical.com

Reply via email to