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