]> www.infradead.org Git - users/jedix/linux-maple.git/commit
Merge branch 'bridge-mc-per-vlan-qquery'
authorDavid S. Miller <davem@davemloft.net>
Wed, 23 Apr 2025 12:02:20 +0000 (13:02 +0100)
committerDavid S. Miller <davem@davemloft.net>
Wed, 23 Apr 2025 12:02:20 +0000 (13:02 +0100)
commit88922fe7854091a50e831fefdae674433c5b261e
tree634a069d326eaaf4a49306f4d258a4a07fd19f82
parent0e0a7e3719bc8cbe6d6e30b3e81f21472ecba5bc
parentaea45363e29dd16050e6ce333ce0d3696ac3b5a9
Merge branch 'bridge-mc-per-vlan-qquery'

Yong Wang says:

====================
bridge: multicast: per vlan query improvement when port or vlan state changes

The current implementation of br_multicast_enable_port() only operates on
port's multicast context, which doesn't take into account in case of vlan
snooping, one downside is the port's igmp query timer will NOT resume when
port state gets changed from BR_STATE_BLOCKING to BR_STATE_FORWARDING etc.

Such code flow will briefly look like:
1.vlan snooping
  --> br_multicast_port_query_expired with per vlan port_mcast_ctx
  --> port in BR_STATE_BLOCKING state --> then one-shot timer discontinued

The port state could be changed by STP daemon or kernel STP, taking mstpd
as example:

2.mstpd --> netlink_sendmsg --> br_setlink --> br_set_port_state with non
  blocking states, i.e. BR_STATE_LEARNING or BR_STATE_FORWARDING
  --> br_port_state_selection --> br_multicast_enable_port
  --> enable multicast with port's multicast_ctx

Here for per vlan snooping, the vlan context of the port should be used
instead of port's multicast_ctx. The first patch corrects such behavior.

Similarly, vlan state change also impacts multicast behavior, the 2nd patch
adds function to update the corresponding multicast context when vlan state
changes.

The 3rd patch adds the selftests to confirm that IGMP/MLD query does happen
when the STP state becomes forwarding.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>