On tor, feb 01, 2024 at 17:24, Jiri Pirko [off-list ref] wrote:

Thu, Feb 01, 2024 at 05:10:45PM CET, tobias@waldekranz.com wrote:

quoted

Before this change, generation of the list of events MDB to replay
would race against the IGMP/MLD snooping logic, which could concurrently
enqueue events to the switchdev deferred queue, leading to duplicate
events being sent to drivers. As a consequence of this, drivers which
reference count memberships (at least DSA), would be left with orphan
groups in their hardware database when the bridge was destroyed.

Avoid this by grabbing the write-side lock of the MDB while generating
the replay list, making sure that no deferred version of a replay
event is already enqueued to the switchdev deferred queue, before
adding it to the replay list.

An easy way to reproduce this issue, on an mv88e6xxx system, was to
create a snooping bridge, and immediately add a port to it:

   root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \
   > ip link set dev x3 up master br0
   root@infix-06-0b-00:~$ ip link del dev br0
   root@infix-06-0b-00:~$ mvls atu
   ADDRESS             FID  STATE      Q  F  0  1  2  3  4  5  6  7  8  9  a
   DEV:0 Marvell 88E6393X
   33:33:00:00:00:6a     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .
   33:33:ff:87:e4:3f     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .
   ff:ff:ff:ff:ff:ff     1  static     -  -  0  1  2  3  4  5  6  7  8  9  a
   root@infix-06-0b-00:~$

The two IPv6 groups remain in the hardware database because the
port (x3) is notified of the host's membership twice: once via the
original event and once via a replay. Since only a single delete
notification is sent, the count remains at 1 when the bridge is
destroyed.

Fixes: 4f2673b3a2b6 ("net: bridge: add helper to replay port and host-joined mdb entries")
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>

Could you please maintain 24 hours period between sending another patch
version?

https://www.kernel.org/doc/html/v6.7/process/maintainer-netdev.html#tl-dr

Sorry, I will avoid that going forward.