[PATCH RFC net-next 0/3] net: dsa: deny unsupported 8021q uppers on bridge ports

Jonas Gorski
2025-11-10T21:45:17Z

Documentation/networking/switchdev.rst is quite strict on how VLAN
uppers on bridged ports should work:

- with VLAN filtering turned off, the bridge will process all ingress traffic
for the port, except for the traffic tagged with a VLAN ID destined for a
VLAN upper. (...)

- with VLAN filtering turned on, these VLAN devices can be created as long as
the bridge does not have an existing VLAN entry with the same VID on any
bridge port. (...)

Presumably with VLAN filtering on, the bridge should also not process
(i.e. forward) traffic destined for a VLAN upper.

But currently, there is no way to tell dsa drivers that a VLAN on a
bridged port is for a VLAN upper and should not be processed by the
bridge.

Both adding a VLAN to a bridge port and adding a VLAN upper to a bridged
port will call dsa_switch_ops::port_vlan_add(), with no way for the
driver to know which is which. But even so, most devices likely would
not support configuring forwarding per VLAN.

So in order to prevent the configuration of configurations with
unintended forwarding between ports:

* deny configuring more than one VLAN upper on bridged ports per VLAN on
VLAN filtering bridges
* deny configuring any VLAN uppers on bridged ports on VLAN non
filtering bridges
* And consequently, disallow disabling filtering as long as there are
any VLAN uppers configured on bridged ports

An alternative solution suggested by switchdev.rst would be to treat
these ports as standalone, and do the filtering/forwarding in software.

But likely DSA supported switches are used on low power devices, where
the performance impact from this would be large.

While going through the code, I also found one corner case where it was
possible to add bridge VLANs shared with VLAN uppers, while adding
VLAN uppers shared with bridge VLANs was properly denied. This is the
first patch as this seems to be like the least controversial.

Sent as a RFC for now due to the potential impact, though a preliminary
test didn't should any failures with bridge_vlan_{un,}aware.sh and
local_termination.sh selftests on BCM63268.

A potential selftest for bridge_vlan_{un,}aware.sh I could think of

- bridge p3, p4
- add VLAN uppers on p1 - p4 with a unique VLAN
if refused, treat as allowed failure
- check if p4 sees traffic from p1

If p1 and p4 are isolated (so implicitly p2 and p3), its fine, and if
the configuration is rejected is also fine, but forwarding is not.

Jonas Gorski (3):
net: dsa: deny bridge VLAN with existing 8021q upper on any port
net: dsa: deny multiple 8021q uppers on bridged ports for the same
VLAN
net: dsa: deny 8021q uppers on vlan unaware bridged ports

net/dsa/port.c | 23 +++------------
net/dsa/user.c | 80 ++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 71 insertions(+), 32 deletions(-)

--
2.43.0