netdev - [PATCH RFC net 0/2] net: dsa: fix handling brentry vlans with flags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250412122428.108029-1-jonas.gorski@gmail.com>
Date: Sat, 12 Apr 2025 14:24:26 +0200
From: Jonas Gorski <jonas.gorski@...il.com>
To: Nikolay Aleksandrov <razor@...ckwall.org>,
	Ido Schimmel <idosch@...dia.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>,
	Andrew Lunn <andrew@...n.ch>,
	Vladimir Oltean <olteanv@...il.com>
Cc: Vladimir Oltean <vladimir.oltean@....com>,
	bridge@...ts.linux.dev,
	netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH RFC net 0/2] net: dsa: fix handling brentry vlans with flags

While trying to figure out the hardware behavior of a DSA supported
switch chip and printing various internal vlan state changes, I noticed
that some flows never triggered adding the cpu port to vlans, preventing
it from receiving any of the VLANs traffic.

E.g. the following sequence would cause the cpu port not being member of
the vlan, despite the bridge vlan output looking correct:

$ ip link add swbridge type bridge vlan_filtering 1 vlan_default_pvid 1
$ 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

Adding more printk debugging, I traced it br_vlan_add_existing() setting
changed to true (since the vlan "gained" the pvid untagged flags), and
then the dsa code ignoring the vlan notification, since it is a vlan for
the cpu port that is updated.

Then I noticed that deleting that vlan didn't work either:

$ 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

which is caused by the same issue, because from the dsa standpoint I am
now trying to delete a non-existing vlan.

After fixing that, both were now correctly working, but the configured
vlan on the cpu port would be stuck with whatever the initial add set.

E.g.:
$ bridge vlan add dev swbridge vid 1 pvid untagged self
$ bridge vlan add dev swbridge vid 1 self

would change the flags in the vlandb, but the hardware configured vlan
would still untag at egress to the cpu port.

Patch two fixes this by allowing changed = true vlan add notifications
for the cpu port, but skip the refcounting. Presumably with the patch
there should never be a vlan add notification for the brentry with
changed set to true anymore.

In case my reasoning is wrong, I added a WARN_ON(), but I didn't get to
trigger it so far.

I did a check of all handlers of switchdev port vlan add notifications,
but DSA seems to be the only one that even looks at the changed flag.

Sent as RFC as I am not too familiar with the dsa/vlan code, so I might
very well have overlooked something.

Jonas Gorski (2):
  net: bridge: switchdev: do not notify new brentries as changed
  net: dsa: propagate brentry flag changes

 net/bridge/br_vlan.c |  4 +++-
 net/dsa/switch.c     | 22 ++++++++++++----------
 2 files changed, 15 insertions(+), 11 deletions(-)

-- 
2.43.0