Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Jonas Gorski <jonas.gorski@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>, Shuah Khan <shuah@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: [PATCH RFC/RFT net-next v2 4/5] net: dsa: deny 8021q uppers on vlan unaware bridged ports
Date: Mon,  1 Dec 2025 11:28:16 +0100	[thread overview]
Message-ID: <20251201102817.301552-5-jonas.gorski@gmail.com> (raw)
In-Reply-To: <20251201102817.301552-1-jonas.gorski@gmail.com>

Documentation/networking/switchdev.rst says:

- 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.

But DSA currently does not notify drivers about uppers on bridge ports
of a VLAN unaware bridge: Bridged ports on a VLAN unaware bridge will
usually not have filtering enabled and thus do not have
NETIF_F_HW_VLAN_CTAG_FILTER so dsa_user_vlan_rx_add_vid() is never
called.

And if filtering is always on for a driver, then DSA will just call
dsa_port_vlan_add(), in the same way it would for VLANs added to the
bridge. And VLANs programmed to the bridge are supposed to be ignored
while filtering is disabled, so drivers would still not act upon it.

Therefore traffic tagged with the VID will continue to be forwarded to
other ports, and therefore we cannot support VLAN uppers on ports of a
VLAN unaware bridges.

So reject any VLAN uppers for bridged ports of VLAN unaware bridges, and
reject disabling filtering as long as any VLAN uppers on bridged ports
exist.

Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
v1 -> v2:
* actually deny VLAN uppers on VLAN-unware bridges
* fix DSA behaviour description for non-filtering bridge ports

 net/dsa/port.c | 23 ++++-------------------
 net/dsa/user.c |  9 ++++++++-
 2 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/net/dsa/port.c b/net/dsa/port.c
index 082573ae6864..d7746885f7e0 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -728,35 +728,20 @@ static bool dsa_port_can_apply_vlan_filtering(struct dsa_port *dp,
 {
 	struct dsa_switch *ds = dp->ds;
 	struct dsa_port *other_dp;
-	int err;
 
-	/* VLAN awareness was off, so the question is "can we turn it on".
+	/* VLAN awareness was on, so the question is "can we turn it off".
 	 * We may have had 8021q uppers, those need to go. Make sure we don't
 	 * enter an inconsistent state: deny changing the VLAN awareness state
 	 * as long as we have 8021q uppers.
 	 */
-	if (vlan_filtering && dsa_port_is_user(dp)) {
-		struct net_device *br = dsa_port_bridge_dev_get(dp);
+	if (!vlan_filtering && dsa_port_is_user(dp)) {
 		struct net_device *upper_dev, *user = dp->user;
 		struct list_head *iter;
 
 		netdev_for_each_upper_dev_rcu(user, upper_dev, iter) {
-			struct bridge_vlan_info br_info;
-			u16 vid;
-
-			if (!is_vlan_dev(upper_dev))
-				continue;
-
-			vid = vlan_dev_vlan_id(upper_dev);
-
-			/* br_vlan_get_info() returns -EINVAL or -ENOENT if the
-			 * device, respectively the VID is not found, returning
-			 * 0 means success, which is a failure for us here.
-			 */
-			err = br_vlan_get_info(br, vid, &br_info);
-			if (err == 0) {
+			if (is_vlan_dev(upper_dev)) {
 				NL_SET_ERR_MSG_MOD(extack,
-						   "Must first remove VLAN uppers having VIDs also present in bridge");
+						   "Must first remove VLAN uppers from bridged ports");
 				return false;
 			}
 		}
diff --git a/net/dsa/user.c b/net/dsa/user.c
index e8c6452780b0..442cf3b2dc30 100644
--- a/net/dsa/user.c
+++ b/net/dsa/user.c
@@ -3167,10 +3167,17 @@ dsa_user_check_8021q_upper(struct net_device *dev,
 	int err = NOTIFY_DONE;
 	u16 vid;
 
-	if (!br || !br_vlan_enabled(br))
+	if (!br)
 		return NOTIFY_DONE;
 
 	extack = netdev_notifier_info_to_extack(&info->info);
+
+	if (!br_vlan_enabled(br)) {
+		NL_SET_ERR_MSG_MOD(extack,
+				   "VLAN uppers not supported with non filtering bridges");
+		return notifier_from_errno(-EBUSY);
+	}
+
 	vid = vlan_dev_vlan_id(info->upper_dev);
 
 	/* br_vlan_get_info() returns -EINVAL or -ENOENT if the
-- 
2.43.0


  parent reply	other threads:[~2025-12-01 10:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-01 10:28 [PATCH RFC/RFT net-next v2 0/5] net: dsa: deny unsupported 8021q upper on bridge port configurations Jonas Gorski
2025-12-01 10:28 ` [PATCH RFC/RFT net-next v2 1/5] net: dsa: deny bridge VLAN with existing 8021q upper on any port Jonas Gorski
2025-12-01 14:47   ` Simon Horman
2025-12-01 19:52     ` Jonas Gorski
2025-12-01 22:48       ` Chris Mason
2025-12-02 16:16         ` Simon Horman
2025-12-03  0:36           ` Chris Mason
2025-12-01 10:28 ` [PATCH RFC/RFT net-next v2 2/5] net: dsa: deny multiple 8021q uppers on bridged ports for the same VLAN Jonas Gorski
2025-12-01 10:28 ` [PATCH RFC/RFT net-next v2 3/5] selftests: no_forwarding: test VLAN uppers on VLAN aware bridged ports Jonas Gorski
2025-12-01 14:19   ` Simon Horman
2025-12-01 19:46     ` Jonas Gorski
2025-12-01 10:28 ` Jonas Gorski [this message]
2025-12-01 10:28 ` [PATCH RFC/RFT net-next v2 5/5] selftests: no_forwarding: test VLAN uppers on VLAN-unaware " Jonas Gorski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251201102817.301552-5-jonas.gorski@gmail.com \
    --to=jonas.gorski@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox