]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
Merge branch 'bridge-check-relevant-options-in-vlan-range-grouping'
authorJakub Kicinski <kuba@kernel.org>
Fri, 27 Feb 2026 03:24:32 +0000 (19:24 -0800)
committerJakub Kicinski <kuba@kernel.org>
Fri, 27 Feb 2026 03:24:33 +0000 (19:24 -0800)
commit7e5b450c490ada6f70e08bbd913f0981d33a5a1a
tree154449f5c9df8448f45a12c7f6d4e2620ef86ebe
parent2ef2b20cf4e04ac8a6ba68493f8780776ff84300
parent13540021be228dcda63d02b2245ce8dad01d8473
Merge branch 'bridge-check-relevant-options-in-vlan-range-grouping'

Danielle Ratson says:

====================
bridge: Check relevant options in VLAN range grouping

The br_vlan_opts_eq_range() function determines if consecutive VLANs can
be grouped together in a range for compact netlink notifications. It
currently checks state, tunnel info, and multicast router configuration,
but misses two categories of per-VLAN options that affect the output:
1. User-visible priv_flags (neigh_suppress, mcast_enabled)
2. Port multicast context options (mcast_max_groups, mcast_n_groups)

When VLANs have different settings for these options, they are incorrectly
grouped into ranges, causing netlink notifications to report only one
VLAN's settings for the entire range.

Fix by checking priv_flags equality, but only for flags that affect netlink
output (BR_VLFLAG_NEIGH_SUPPRESS_ENABLED and BR_VLFLAG_MCAST_ENABLED),
and comparing multicast context options (mcast_max_groups, mcast_n_groups).

Add a test with four test cases for each option, to ensure that VLANs with
different values are not grouped into ranges and VLANs with matching
values are properly grouped together.
====================

Link: https://patch.msgid.link/20260225143956.3995415-1-danieller@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>