netdev - Re: [PATCH v3 net-next 1/4] net: bonding: Notify ports about their initial state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87h7p37u4t.fsf@waldekranz.com>
Date:   Wed, 02 Dec 2020 22:52:50 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Jay Vosburgh <jay.vosburgh@...onical.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com, olteanv@...il.com,
        vfalico@...il.com, andy@...yhouse.net, netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 1/4] net: bonding: Notify ports about their initial state

On Wed, Dec 02, 2020 at 11:09, Jay Vosburgh <jay.vosburgh@...onical.com> wrote:
> Tobias Waldekranz <tobias@...dekranz.com> wrote:
>
>>When creating a static bond (e.g. balance-xor), all ports will always
>>be enabled. This is set, and the corresponding notification is sent
>>out, before the port is linked to the bond upper.
>>
>>In the offloaded case, this ordering is hard to deal with.
>>
>>The lower will first see a notification that it can not associate with
>>any bond. Then the bond is joined. After that point no more
>>notifications are sent, so all ports remain disabled.
>>
>>This change simply sends an extra notification once the port has been
>>linked to the upper to synchronize the initial state.
>
> 	I'm not objecting to this per se, but looking at team and
> net_failover (failover_slave_register), those drivers do not send the
> same first notification that bonding does (the "can not associate" one),
> but only send a notification after netdev_master_upper_dev_link is
> complete.
>
> 	Does it therefore make more sense to move the existing
> notification within bonding to take place after the upper_dev_link
> (where you're adding this new call to bond_lower_state_changed)?  If the
> existing notification is effectively useless, this would make the
> sequence of notifications consistent across drivers.

>From my point of view that makes more sense. I just assumed that the
current implementation was done this way for a reason. Therefore I opted
for a simple extension instead.

I could look at hoisting up the linking op before the first
notification. My main concern is that this is a new subsystem to me, so
I am not sure how to determine the adequate test coverage for a change
like this.

Another option would be to drop this change from this series and do it
separately. It would be nice to have both team and bond working though.

Not sure why I am the first to run into this. Presumably the mlxsw LAG
offloading would be affected in the same way. Maybe their main use-case
is LACP.