Re: [BUG] 6.14: WARNING: CPU: 0 PID: 478 at net/bridge/br_vlan.c:433 nbp_vlan_flush+0xc0/0xc4

[Vladimir Oltean <olteanv@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Fri, Apr 11, 2025 at 06:24:44PM +0100, Russell King (Oracle) wrote:
> Hi,
> 
> When executing:
> 
> # ifdown br0
> 
> on the ZII dev rev B platform with br0 being a bridge between mv88e6xxx
> DSA ports, the following was spewed:
> 
> [  628.418720] br0: port 9(optical2) failed to delete vlan 1: -ENOENT

(trimming the rest, which is just the bridge complaining that &vg->vlan_list
is not empty, but __vlan_del() aborted the VLAN deletion due to
br_switchdev_port_vlan_del() returning an error, and left the VLAN in
the VLAN group's list. So that part is expected and is just a symptom,
we should focus on why DSA returns -ENOENT when requesting to delete
VLAN 1 from the CPU port).

Please test the attached patch. This is more speculative, but I've run
all the options in my mind and this is the only thing that makes sense.

[-- Attachment #2: 0001-net-dsa-mv88e6xxx-fix-ENOENT-while-deleting-user-por.patch --]
[-- Type: text/x-diff, Size: 2058 bytes --]

From 508d912b5f6b56c3f588b1bf28d3caed9e30db1b Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 11 Apr 2025 21:38:52 +0300
Subject: [PATCH] net: dsa: mv88e6xxx: fix -ENOENT while deleting user port
 VLANs

Russell King reports that on the ZII dev rev B, deleting a bridge VLAN
from a user port fails with -ENOENT:
https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/

This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(),
which tries to find an MST entry in &chip->msts associated with the SID,
but fails and returns -ENOENT as such.

But we know that this chip does not support MST at all, so that is not
surprising. The question is why does the guard in mv88e6xxx_mst_put()
not exit early:

	if (!sid)
		return 0;

And the answer seems to be simple: the sid comes from vlan.sid which
supposedly was previously populated by mv88e6xxx_vtu_loadpurge().
But some chip->info->ops->vtu_loadpurge() implementations do not look at
vlan.sid at all, for example see mv88e6185_g1_vtu_loadpurge().

It was probably intended for the on-stack struct mv88e6xxx_vtu_entry
vlan entry to be zero-initialized, because currently it looks like we're
looking at a garbage sid which is just residual stack memory. So
zero-initialize this to avoid MST operations on switches which don't
support MST.

Fixes: acaf4d2e36b3 ("net: dsa: mv88e6xxx: MST Offloading")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 29a89ab4b789..c94c228434fc 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2706,7 +2706,7 @@ static int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
 static int mv88e6xxx_port_vlan_leave(struct mv88e6xxx_chip *chip,
 				     int port, u16 vid)
 {
-	struct mv88e6xxx_vtu_entry vlan;
+	struct mv88e6xxx_vtu_entry vlan = {};
 	int i, err;
 
 	if (!vid)
-- 
2.34.1