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]

Date:   Tue, 23 Feb 2021 21:29:09 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     Vladimir Oltean <olteanv@...il.com>
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 08:02:36PM +0200, Vladimir Oltean wrote:
> 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?

Not sure. It needs to be scheduled when the driver is ready to handle
it. In br_add_if() after netdev_master_upper_dev_link() is probably a
good place.

It also needs to be done once and not every time another port joins the
bridge. This can be done using the port's parent ID, similar to what we
are already doing with the offload forward mark in
nbp_switchdev_mark_set().

But I'm not sure how we replay it only for a single notifier block. I'm
not familiar with setups where you have more than one listener let alone
more than one that is interested in notifications from a specific
bridge, so maybe it is OK to just replay it for all the listeners. But I
would prefer to avoid it if we can.