From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4CA1303A22 for ; Mon, 1 Dec 2025 10:28:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764584930; cv=none; b=dwrch+9WoimTvlrYbbQ6PwycBSfNQkypatPMkicc3r5utaGKuCImUj7fAWlbyYCoBLT/Py80XrXuTtU3ViBKjLshOeQ+xbhqf9JMHN8T/C5iMgQXXea+ZOje2vqfnDDNSS+CJ2QeIqzxuhmjtHYaQauk05AD3DV8ufFWgnYQQ9I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764584930; c=relaxed/simple; bh=coKQmnQOeVL2OgF0ptAkfJC94MDFt2dY6q7vB6WFLOw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=nJkbUhBcm+ovPDv/UQ+LFzTDiZWY2KQDebOU59jfX4fanlo29WpEn7iOBThq+UEfLKs4t0Jumzhl0zg3FnaSJ42dA2SVwP48yI6B81CQMETOT8qOoosSni2Gb0Xf4MEkjoJa5deckthG1KUstVkVEF872hZu50Jpozj/LA3tfEk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=eRHchNO7; arc=none smtp.client-ip=209.85.208.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eRHchNO7" Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-6406f3dcc66so6989222a12.3 for ; Mon, 01 Dec 2025 02:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764584927; x=1765189727; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=Trv2vBQvyezhPFCSlLnIlg78sYOVaGWphXC4AQCe9So=; b=eRHchNO78riX9WOSFDzaI6092nBLp/OYpUwukl8uniM+1J2CKZizKv7yaiGZspgKdU X9tM9GMVOyQG64GbCO+09+3LvypHLAV9w+d392LuQrIRpzrJk4Lk2pXcmGKW6j3DmIaR yLPgpPqMzw7YZsF18c22Nfm2/DTAkyTgW+veYjt3Plr5JBdzEdbW//qoVe7Z6TtGXH+I eGj/WWpKLMmUf3rwlY706NBHZdu/qRoFX7IOTLrNHYr6Z2BmZegx12TKK8OkqXvIqOmL vsZILymUye0SR9Ft4gMf4iFitgZZjaRVs9vZ9Jb6dSwjzdsFQ3H/4sfX9BPwXBsz9lco NLPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764584927; x=1765189727; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Trv2vBQvyezhPFCSlLnIlg78sYOVaGWphXC4AQCe9So=; b=PdMxLLPa+fUwifm0O3Nx0XOJwv5M7MoGKPwDim5lj0PpN7Eaz/P2f9aGsanMMibNkU T1ZNKtf1HPEqEtuW8a1ivGNlqIiGybh2Xe1Vcfn55dpyBTx/4aWTDqQIsbO+MEKDVHNV s13Z451jD/8J7O7ZK6Em/YX1K+xKRKDAJbX3NZaf4qMAe3i7wOYqkccCILqXWfVC7eWw /vk5295VGELwFy/aNVFxMTTx13u0nM8ffsSGBdOOO2hN3WVpFzFBvaeGzZcsuwhCFgZ9 SXSvVnB3D3kjK3FnG8ZftlMkxNBFwApVh819eIAnLKadXY1oTd+9cJF/F/vMWsiFDV3M DHFA== X-Forwarded-Encrypted: i=1; AJvYcCV7bZladIQGHtu4ymKoAkdLiHpUb+PKjmf/AnpsMM5RHuDekYS3ObqHb+DtmhtGspJtqO5hhevbf1DP06E=@vger.kernel.org X-Gm-Message-State: AOJu0Yy6b3AkICR1A+JgJjEM9WTlSRAKxjfFcjH9+wt5hyrrd8ZIu6zO VdmP3L2qgGTc/hRBwHhFquzg+7+TTGHipkkZeN4V+9OShq1sQLmBfD9P X-Gm-Gg: ASbGnctd2WvTBmgDwM7lLyjotZ+zep/LD4zxDS6v4+RUoEOWnqoOIyjilMHcimN4IXh zZXN1mDL/zTht4ARSK+xsMZWDBOn26mbywzU4VgdCh3Ah0vmHyqsh95M++yMCQc/lXYoYFx2nuU 2P0Q7K4pbZ6ftZLo1p1754GonxlF0vTpGW/7+1wIniKrIKHt1UXLEL+nIAtLJ/lS/0h1L57ZE7E jhyDYt1jN85cmpNFMnaHazbDPy+eqRDYa0UTQQR9T+wfZvsR7YYdzse1YdQ/wETt8V8KiHIyI+o 3sRttXzwNZtW7h2XUF477fbwnE58XYIdktTR7Ws1iMiqoczakAoqT4iTgzo09v/6OtbwnTwTKpR vSASUGBj37xR6IHL9yClBSZyKOWiX/M17yqE703Z74Ur0sjL95aOJmvYAYw/3ghKs6LZ/ptAMzs qzh2PDojqqPeg9uQH3HXwlkJa2kaMRKQ2hF0KD6rwnD+viJ+sjDsFaJMcTN1WmmKSbWcs= X-Google-Smtp-Source: AGHT+IEpYaDw6CB+PRG4a7CypPzPVOz1eYsdJhEGj+ut8QOSYl9UkcEcJaF3eu3S807y5FJLxRb/8A== X-Received: by 2002:a17:906:fe49:b0:b72:b289:6de3 with SMTP id a640c23a62f3a-b76719d0982mr4315736866b.58.1764584926734; Mon, 01 Dec 2025 02:28:46 -0800 (PST) Received: from localhost (dslb-002-205-018-238.002.205.pools.vodafone-ip.de. [2.205.18.238]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b76f5162d31sm1193157766b.9.2025.12.01.02.28.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Dec 2025 02:28:46 -0800 (PST) From: Jonas Gorski To: Andrew Lunn , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , Florian Fainelli Cc: Vladimir Oltean , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH RFC/RFT net-next v2 0/5] net: dsa: deny unsupported 8021q upper on bridge port configurations Date: Mon, 1 Dec 2025 11:28:12 +0100 Message-ID: <20251201102817.301552-1-jonas.gorski@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Documentation/networking/switchdev.rst is quite strict on how VLAN uppers on bridged ports should work: - 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. (...) - with VLAN filtering turned on, these VLAN devices can be created as long as the bridge does not have an existing VLAN entry with the same VID on any bridge port. (...) This means that VLAN tagged traffic matching a VLAN upper is never forwarded from that port (unless the VLAN upper itself is bridged). It does *not* mean that VLAN tagged traffic matching a VLAN upper is not forwarded to that port anymore, as VLAN uppers only consume ingressing traffic. Currently, there is no way to tell dsa drivers that a VLAN on a bridged port is for a VLAN upper and should not be processed by the bridge. Both adding a VLAN to a bridge port of bridge and adding a VLAN upper to a bridged port of a VLAN-aware bridge will call dsa_switch_ops::port_vlan_add(), with no way for the driver to know which is which. In case of VLAN-unaware bridges, there is likely no dsa_switch_ops::port_vlan_add() call at all for the VLAN upper. But even if DSA told drivers which type of VLAN this is, most devices likely would not support configuring forwarding per VLAN per port. So in order to prevent the configuration of setups with unintended forwarding between ports: * deny configuring more than one VLAN upper on bridged ports per VLAN on VLAN filtering bridges * deny configuring any VLAN uppers on bridged ports on VLAN non filtering bridges * And consequently, disallow disabling filtering as long as there are any VLAN uppers configured on bridged ports An alternative solution suggested by switchdev.rst would be to treat these ports as standalone, and do the filtering/forwarding in software. But likely DSA supported switches are used on low power devices, where the performance impact from this would be large. To verify that this is needed, add appropriate selftests to no_forwarding to verify either VLAN uppers are denied, or VLAN traffic is not unexpectedly (still) forwarded. These test succeed with a veth-backed software bridge, but fail on a b53 device without the DSA changes applied. While going through the code, I also found one corner case where it was possible to add bridge VLANs shared with VLAN uppers, while adding VLAN uppers shared with bridge VLANs was properly denied. This is the first patch as this seems to be like the least controversial. Still sent as a RFC/RFT for now due to the potential impact, though a preliminary test didn't should any failures with bridge_vlan_{un,}aware.sh and local_termination.sh selftests on BCM63268. Also since net-next is closed (though I'm not sure yet if this is net or net-next material, since this just properly prevents broken setups). Changes v1 -> v2: * added selftests for both VLAN-aware and VLAN-unaware bridges * actually disallow VLAN uppers on VLAN-unware bridges, not disallow more than one * fixed the description of VLAN upper notification behaviour of DSA with filtering disabled Jonas Gorski (5): net: dsa: deny bridge VLAN with existing 8021q upper on any port net: dsa: deny multiple 8021q uppers on bridged ports for the same VLAN selftests: no_forwarding: test VLAN uppers on VLAN aware bridged ports net: dsa: deny 8021q uppers on vlan unaware bridged ports selftests: no_forwarding: test VLAN uppers on VLAN-unaware bridged ports net/dsa/port.c | 23 +--- net/dsa/user.c | 51 ++++++--- .../selftests/net/forwarding/no_forwarding.sh | 107 ++++++++++++++---- 3 files changed, 127 insertions(+), 54 deletions(-) base-commit: 0177f0f07886e54e12c6f18fa58f63e63ddd3c58 -- 2.43.0