[PATCH RFC/RFT net-next v2 0/5] net: dsa: deny unsupported 8021q upper on bridge port configurations

Jonas Gorski
2025-12-01T10:28:48Z

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. (...)

This means that VLAN tagged traffic matching a VLAN upper is never
forwarded from that port (unless the VLAN upper itself is bridged).

It does *not* mean that VLAN tagged traffic matching a VLAN upper is not
forwarded to that port anymore, as VLAN uppers only consume ingressing
traffic.

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 of bridge and adding a VLAN upper to
a bridged port of a VLAN-aware bridge will call
dsa_switch_ops::port_vlan_add(), with no way for the driver to know
which is which. In case of VLAN-unaware bridges, there is likely no
dsa_switch_ops::port_vlan_add() call at all for the VLAN upper.

But even if DSA told drivers which type of VLAN this is, most devices
likely would not support configuring forwarding per VLAN per port.

So in order to prevent the configuration of setups 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.

To verify that this is needed, add appropriate selftests to
no_forwarding to verify either VLAN uppers are denied, or VLAN traffic
is not unexpectedly (still) forwarded.

These test succeed with a veth-backed software bridge, but fail on a b53
device without the DSA changes applied.

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.

Still sent as a RFC/RFT 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.

Also since net-next is closed (though I'm not sure yet if this is net or
net-next material, since this just properly prevents broken setups).

Changes v1 -> v2:

* added selftests for both VLAN-aware and VLAN-unaware bridges
* actually disallow VLAN uppers on VLAN-unware bridges, not disallow
more than one
* fixed the description of VLAN upper notification behaviour of DSA with
filtering disabled

Jonas Gorski (5):
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
selftests: no_forwarding: test VLAN uppers on VLAN aware bridged ports
net: dsa: deny 8021q uppers on vlan unaware bridged ports
selftests: no_forwarding: test VLAN uppers on VLAN-unaware bridged
ports

net/dsa/port.c | 23 +---
net/dsa/user.c | 51 ++++++---
.../selftests/net/forwarding/no_forwarding.sh | 107 ++++++++++++++----
3 files changed, 127 insertions(+), 54 deletions(-)

base-commit: 0177f0f07886e54e12c6f18fa58f63e63ddd3c58
--
2.43.0