On Mon, Apr 14, 2025 at 10:00:20PM +0200, Jonas Gorski wrote:
> When adding a bridge vlan that is pvid or untagged after the vlan has
> already been added to any other switchdev backed port, the vlan change
> will be propagated as changed, since the flags change.
>
> This causes the vlan to not be added to the hardware for DSA switches,
> since the DSA handler ignores any vlans for the CPU or DSA ports that
> are changed.
>
> E.g. the following order of operations would work:
>
> $ ip link add swbridge type bridge vlan_filtering 1 vlan_default_pvid 0
> $ ip link set lan1 master swbridge
> $ bridge vlan add dev swbridge vid 1 pvid untagged self
> $ bridge vlan add dev lan1 vid 1 pvid untagged
>
> but this order would break:
>
> $ ip link add swbridge type bridge vlan_filtering 1 vlan_default_pvid 0
> $ ip link set lan1 master swbridge
> $ bridge vlan add dev lan1 vid 1 pvid untagged
> $ bridge vlan add dev swbridge vid 1 pvid untagged self
>
> Additionally, the vlan on the bridge itself would become undeletable:
>
> $ bridge vlan
> port vlan-id
> lan1 1 PVID Egress Untagged
> swbridge 1 PVID Egress Untagged
> $ bridge vlan del dev swbridge vid 1 self
> $ bridge vlan
> port vlan-id
> lan1 1 PVID Egress Untagged
> swbridge 1 Egress Untagged
>
> since the vlan was never added to DSA's vlan list, so deleting it will
> cause an error, causing the bridge code to not remove it.
>
> Fix this by checking if flags changed only for vlans that are already
> brentry and pass changed as false for those that become brentries, as
> these are a new vlan (member) from the switchdev point of view.
>
> Since *changed is set to true for becomes_brentry = true regardless of
> would_change's value, this will not change any rtnetlink notification
> delivery, just the value passed on to switchdev in vlan->changed.
>
> Fixes: 8d23a54f5bee ("net: bridge: switchdev: differentiate new VLANs from
> changed ones")
> Reviewed-by: Vladimir Oltean <vladimir.olt...@nxp.com>
> Signed-off-by: Jonas Gorski <jonas.gor...@gmail.com>
Reviewed-by: Ido Schimmel <ido...@nvidia.com>
