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

[Jonas Gorski]

Hi Vladimir,

On Tue, Nov 11, 2025 at 12:01 AM Vladimir Oltean <olteanv@xxxxxxxxx> wrote:
>
> Hi Jonas,
>
> On Mon, Nov 10, 2025 at 10:44:40PM +0100, Jonas Gorski wrote:
> > 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.
>
> You say this as if it mattered. We can add a distinguishing mechanism
> (for example we can pass a struct dsa_db to .port_vlan_add(), set to
> DSA_DB_PORT for VLAN RX filtering and DSA_DB_BRIDGE for bridge VLANs),
> but the premise was that drivers don't need to care, because HW won't do
> anything useful with that information.

It matters in the case of VLAN uppers on bridged ports. It does not
matter for VLAN uppers on standalone ports.

> > 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.
>
> Yes, this is why the status quo is that DSA tries to ensure that VLAN
> uppers do not cause ports to forward packets between each other.
> You are not really changing the status quo in any way, just fixing some
> bugs where that didn't happen effectively. Perhaps you could make that a
> bit more clear.

Right, I'm trying to prevent situations where the forwarding will
happen despite not being supposed to happen.

> > 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
>
> First bullet makes some sense, bullets 2 and 3 not so much.
>
> The first bullet makes just "some" sense because I don't understand why
> limit to just bridged ports. We should extend to all NETIF_F_HW_VLAN_CTAG_FILTER
> ports as per the dsa_user_manage_vlan_filtering() definitions.

Standalone ports are isolated from each other, so the configured VLAN
uppers do not matter for forwarding. They will (should) never forward
traffic to other ports, regardless of any VLAN (filtering)
configuration on the bridge, so there is no issue here (pending
correct programming of the switch). Usually isolation trumps any VLAN
memberships.

This is purely about unintended/forbidden forwarding between bridged ports.

> Bullets 2 and 3 don't make sense because it isn't explained how VLAN
> non-filtering bridge ports could gain the NETIF_F_HW_VLAN_CTAG_FILTER
> feature required for them to see RX filtering VLANs programmed to
> hardware in the first place.

Let me try with an example:

let's say we have swp1 - swp4, standalone.

allowed forward destinations for all are the cpu port, no filtering.

now we create a bridge between swp2 and swp3.

now swp2 may also forward to swp3, and swp3 to swp2.

swp1 and swp4 may still only forward to cpu (and this doesn't change
here. We can ignore them).

Bullet point 1:

If vlan_filtering is enabled, swp2 and swp3 will only forward configured VLANs.

swp2 and swp3 will have NETIF_F_HW_VLAN_CTAG_FILTER (as VLAN filtering
is enabled on these ports).

If we enable VID 10 on both ports, the driver will be called with
port_vlan_add(.. vid = 10), and they forward VLAN 10 between each
other.
If we instead create uppers for VID 10 for both ports, the driver will
be called with port_vlan_add(... vid = 10) (as
NETIF_F_HW_VLAN_CTAG_FILTER is is set), and they forward VLAN 10
between each other (oops).

Bullet point 2:

If vlan_filtering is disabled, swp2 and swp3 forward any VID between each other.

swp2 and swp3 won't have NETIF_F_HW_VLAN_CTAG_FILTER (as vlan
filtering is disabled on these ports).

If we now create an upper for VID 10 on swp2, then VLAN 10 should not
be forwarded to swp3 anymore (as VLAN 10 is now "consumed" by the host
on this port).

But since there is no port_vlan_add() call due to filtering disabled
(NETIF_F_HW_VLAN_CTAG_FILTER not set), the dsa driver does not know
that the forwarding should be inhibited between these ports, and VLAN
10 is still forwarded from swp2 to swp3 (oops).

Bullet point 3:
And since having uppers on a bridged ports on a non-filtering bridge
does not inhibit forwarding at all, we cannot allow disabling
filtering as long as VLAN uppers on bridged ports exist.

Does this now make it clearer what situations I am talking about?

The easy way is to disallow these configurations, which is what I try
to attempt (explicitly allowed by switchdev.rst).

One other more expensive options are making bridge ports with VLAN
uppers (or more than one upper for a VLAN) standalone and disable
forwarding, and only do forwarding in software.

Or add the above mentioned DSA_DB_PORT for vlan uppers on (bridged)
ports, regardless of filtering being enabled, and then let the dsa
driver handle forwarding per VLAN. This may or may not be possible,
depending on the hardware. One workaround I can think of is to enable
a VLAN membership violation trap and then remove the port from the
VLAN. But this also has the potential to pull a lot of traffic to the
cpu. And requires drivers to be adapted to handle it. And would
require filtering, which may get complicated for the non-filtering
bridge case.

> > 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.
>
> Sounds like something which would be fit for
> tools/testing/selftests/net/forwarding/no_forwarding.sh.

Oh, wasn't aware of this one, yeah, that seems appropriate. Thanks!
Will try to come up with a test.

Best Regards,
Jonas