netdev - Re: Timing of host-joined bridge multicast groups with switchdev

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: <20210223180236.e2ggiuxhr5aaayx5@skbuf>
Date:   Tue, 23 Feb 2021 20:02:36 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Nikolay Aleksandrov <nikolay@...dia.com>,
        Roopa Prabhu <roopa@...dia.com>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Subject: Re: Timing of host-joined bridge multicast groups with switchdev

On Tue, Feb 23, 2021 at 07:56:22PM +0200, Ido Schimmel wrote:
> For route offload you get a dump of all the existing routes when you
> register your notifier. It's a bit different with bridge because you
> don't care about existing bridges when you just initialize your driver.
>
> We had a similar issue with VXLAN because its FDB can be populated and
> only then attached to a bridge that you offload. Check
> vxlan_fdb_replay(). Probably need to introduce something similar for
> FDB/MDB entries.

So you would be in favor of a driver-voluntary 'pull' type of approach
at bridge join, instead of the bridge 'pushing' the addresses?

That's all fine, except when we'll have more than 3 switchdev drivers,
how do we expect to manage all this complexity duplicated in many places
in the kernel, instead of having it in a central place? Are there corner
cases I'm missing which make the 'push' approach impractical?