linux-kernel - Re: [PATCH/RFC net] net: dsa: lantiq_gswip: honor dsa_db passed to port_fdb

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: <20250810210200.6n3xguqi5ukbybm2@skbuf>
Date: Mon, 11 Aug 2025 00:02:00 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Hauke Mehrtens <hauke@...ke-m.de>, Andrew Lunn <andrew@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Arkadi Sharshevsky <arkadis@...lanox.com>,
	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Andreas Schirm <andreas.schirm@...mens.com>,
	Alexander Sverdlin <alexander.sverdlin@...mens.com>,
	Lukas Stockmann <lukas.stockmann@...mens.com>,
	John Crispin <john@...ozen.org>
Subject: Re: [PATCH/RFC net] net: dsa: lantiq_gswip: honor dsa_db passed to
 port_fdb_{add,del}

On Sun, Aug 10, 2025 at 05:54:55PM +0100, Daniel Golle wrote:
> As it would be nice to have the proper fix backported at least all the way
> down to linux-6.1.y, do you think it would be ok to have that solution
> I proposed (and picked from the GPL-2.0 licensed vendor driver) applied to
> the 'net' tree (with a more appropriate Fixes: tag and commit description,
> obviously) and either just not fix it for linux-5.15.y, or only there
> replace the 'return -EINVAL;' with a 'dev_warn(...); return 0;'?
> 
> In fact, commit c26933639b54 ("net: dsa: request drivers to perform FDB
> isolation") also touches drivers/net/dsa/lantiq_gswip.c and does add
> struct dsa_db as parameter for the .port_fdb_{add,del} ops. Would it be
> ok to hence target that commit in the Fixes: tag?

Generally the commit from the Fixes: tag is the one which "git bisect"
points to, when monitoring the described problem.

If the problem are the error messages, the proper fix which restores
previous behavior would be returning zero with no further logging.

If the problem is the lack of host FDB entries from the hardware, the
new logic to be properly tested in a context where it makes a real difference.
I suggest tools/testing/selftests/net/forwarding/local_termination.sh
once dsa_switch_supports_uc_filtering() returns true. Otherwise, the CPU
port must be in the flood mask of bridged user ports in order to receive
unknown traffic, and for the basic usage, I don't see much practical
benefit from adding host FDB entries to hardware. One situation is when
there are 2 bridged ports A and B, and the station connected to A wants
to talk to the CPU (the bridge net device), what will happen is the
station connected to port B will also see this traffic due to flooding.
Anyway, that behavior has existed since forever for drivers which don't
learn the MAC SA from host-transmitted packets, and don't have functional
software-based host RX filtering.

So I'm concerned that if you try to push solution B for problem A, and
test it only for problem A's circumstances and current requirements,
this will create the premise for a never-ending rabbit hole of further
fixups onto the new logic, sent to stable kernels.