On 10/23/25 17:45, Petr Machata wrote: > When forwarding multicast packets, the bridge takes MDB into account when > IGMP / MLD snooping is enabled. Currently, when snooping is disabled, the > MDB is retained, even though it is not used anymore. > > At the same time, during the time that snooping is disabled, the IGMP / MLD > control packets are obviously ignored, and after the snooping is reenabled, > the administrator has to assume it is out of sync. In particular, missed > join and leave messages would lead to traffic being forwarded to wrong > interfaces. > > Keeping the MDB entries around thus serves no purpose, and just takes > memory. Note also that disabling per-VLAN snooping does actually flush the > relevant MDB entries. > > This patch flushes non-permanent MDB entries as global snooping is > disabled. > > Signed-off-by: Petr Machata <[email protected]> > Reviewed-by: Ido Schimmel <[email protected]> > --- > net/bridge/br_multicast.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c > index 22d12e545966..d55a4ab87837 100644 > --- a/net/bridge/br_multicast.c > +++ b/net/bridge/br_multicast.c > @@ -4649,6 +4649,14 @@ static void br_multicast_start_querier(struct > net_bridge_mcast *brmctx, > rcu_read_unlock(); > } > > +static void br_multicast_del_grps(struct net_bridge *br) > +{ > + struct net_bridge_port *port; > + > + list_for_each_entry(port, &br->port_list, list) > + __br_multicast_disable_port_ctx(&port->multicast_ctx); > +} > + > int br_multicast_toggle(struct net_bridge *br, unsigned long val, > struct netlink_ext_ack *extack) > { > @@ -4669,6 +4677,7 @@ int br_multicast_toggle(struct net_bridge *br, unsigned > long val, > br_opt_toggle(br, BROPT_MULTICAST_ENABLED, !!val); > if (!br_opt_get(br, BROPT_MULTICAST_ENABLED)) { > change_snoopers = true; > + br_multicast_del_grps(br); > goto unlock; > } >
I've actually thought about this, disabling multicast has always been weird in the bridge and I think this is an improvement: Acked-by: Nikolay Aleksandrov <[email protected]>
