netdev - Re: [RFC net-next 0/6] offload linux bonding tc ingress rules

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: <20180306074940.GA14599@splinter>
Date:   Tue, 6 Mar 2018 09:49:40 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     John Hurley <john.hurley@...ronome.com>
Cc:     netdev@...r.kernel.org, jiri@...lanox.com, ogerlitz@...lanox.com,
        jakub.kicinski@...ronome.com, simon.horman@...ronome.com
Subject: Re: [RFC net-next 0/6] offload linux bonding tc ingress rules

On Mon, Mar 05, 2018 at 01:28:28PM +0000, John Hurley wrote:
> To prevent sync issues between the kernel and offload device, the linux
> bond driver is affectively locked when it has offloaded rules. i.e no new
> ports can be enslaved and no slaves can be released until the offload
> rules are removed. Similarly, if a port on a bond is deleted, the bond is
> destroyed, forcing a flush of all offloaded rules.

Hi John,

I understand where this is coming from, but I don't think these
semantics are acceptable. The part about not adding new slaves might
make sense, but one needs to be able to remove slaves at any time.

Anyway, it would be much better to handle this in a generic way that
team and other stacked devices can later re-use. There's a similar sync
issue with VLAN filtering, which is handled by bond/team by calling
vlan_vids_add_by_dev() and vlan_vids_del_by_dev() in their
ndo_add_slave() and ndo_del_slave(), respectively. You can do something
similar and call into TC to replay the necessary information to the
newly added slave?