Message-ID: <20251110214443.342103-1-jonas.gorski@gmail.com>
Date: Mon, 10 Nov 2025 22:44:40 +0100
From: Jonas Gorski <jonas.gorski@...il.com>
To: Andrew Lunn <andrew@...n.ch>,
	Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Florian Fainelli <f.fainelli@...il.com>
Cc: Vladimir Oltean <vladimir.oltean@....com>,
	netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH RFC net-next 0/3] net: dsa: deny unsupported 8021q uppers on bridge ports

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

Powered by blists - more mailing lists