linux-kernel - Re: [PATCH v5 net-next 12/14] bridge: No DEV_PATH_BR_VLAN_UNTAG

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-prev] [day] [month] [year] [list]

Message-ID: <20250207220408.zipucrmm2yafj4wu@skbuf>
Date: Sat, 8 Feb 2025 00:04:08 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Eric Woudstra <ericwouds@...il.com>
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
	"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>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	Jozsef Kadlecsik <kadlec@...filter.org>,
	Jiri Pirko <jiri@...nulli.us>, Ivan Vecera <ivecera@...hat.com>,
	Roopa Prabhu <roopa@...dia.com>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Kuniyuki Iwashima <kuniyu@...zon.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Lorenzo Bianconi <lorenzo@...nel.org>,
	Joe Damato <jdamato@...tly.com>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Frank Wunderlich <frank-w@...lic-files.de>,
	Daniel Golle <daniel@...rotopia.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, netfilter-devel@...r.kernel.org,
	coreteam@...filter.org, bridge@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v5 net-next 12/14] bridge: No DEV_PATH_BR_VLAN_UNTAG_HW
 for dsa foreign

On Fri, Feb 07, 2025 at 09:04:28PM +0100, Eric Woudstra wrote:
> Or should mlxsw_sp_switchdev_blocking_event() use
> switchdev_handle_port_obj_add_foreign() to add the vxlan
> foreign port?
> 
> Then all foreign ports are added in a uniform manner and
> SWITCHDEV_F_NO_FOREIGN is respected.
> 
> I do not have the hardware to test any changes in that code.

Personally, in your place I wouldn't have the courage to refactor that
much in a driver as complex as spectrum, but if you CC the right people
from Nvidia who can test, I guess you could give that a try.

Actually, how I came to spectrum was that I was thinking about an
alternative mechanism of detecting "foreign or not", other than emitting
two switchdev notifiers. You emit just the usual, single one, but
whoever handles it for a foreign bridge port will set a new bool
port_obj_info->handled_by_foreign, very similar to the existing
bool port_obj_info->handled. I was looking around to see who else
open-codes the switchdev object handling rather than use the
switchdev_handle_*() helpers, and that's how I came across spectrum.
It would seem, at first glance, easier to set just this in spectrum:

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 6397ff0dc951..6926aaae7278 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -3953,6 +3953,7 @@ mlxsw_sp_switchdev_vxlan_vlans_add(struct net_device *vxlan_dev,
 		return 0;

 	port_obj_info->handled = true;
+	port_obj_info->handled_by_foreign = true;

 	bridge_device = mlxsw_sp_bridge_device_find(mlxsw_sp->bridge, br_dev);
 	if (!bridge_device)

and this in the object replication helper:

diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index c48f66643e99..be82e79b5feb 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -763,6 +763,8 @@ static int __switchdev_handle_port_obj_add(struct net_device *dev,
 	if (!foreign_dev_check_cb(switchdev, dev))
 		return err;

+	port_obj_info->handled_by_foreign = true;
+
 	return __switchdev_handle_port_obj_add(br, port_obj_info, check_cb,
 					       foreign_dev_check_cb, add_cb);
 }

Just some care needs to be taken to only consider "handled_by_foreign"
just when "handled" is true.

I haven't yet decided which variant I like better, just thought I'd
mention this as something which requires a single switchdev notification.

Anyway, in the future I'll have to do some more tweaks with these flags
in the context of LAG. These flags (BR_VLFLAG_ADDED_BY_SWITCHDEV, now
also BR_VLFLAG_TAGGING_BY_SWITCHDEV after this patch) can dynamically
change, and the existing code isn't great because it doesn't handle that.

For example:

ip link add br0 type bridge
ip link set swp0 master br0
ip link set bond0 master br0 # bond0 is a foreign interface to swp0 at this time
bridge vlan add dev bond0 vid 100 # this won't get BR_VLFLAG_TAGGING_BY_SWITCHDEV
ip link set swp1 master bond0 # bond0 is no longer a foreign interface to swp0, assuming the same phys_switch_id
# vid 100 should get BR_VLFLAG_TAGGING_BY_SWITCHDEV during br_switchdev_vlan_replay()

Considering that br_switchdev_vlan_replay() will need to re-evaluate the
BR_VLFLAG_TAGGING_BY_SWITCHDEV flag, I guess I do prefer the simpler
variant after all - it is one call less that will have to be made during
replay as well.