netdev - Re: [PATCH v4 nf-next 0/2] flow offload teardown when layer 2 roaming

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

Message-ID: <346ffcf3-cf42-4227-96c5-84d37837c09f@gmail.com>
Date: Tue, 7 Oct 2025 10:47:04 +0200
From: Eric Woudstra <ericwouds@...il.com>
To: Florian Westphal <fw@...len.de>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
 Jozsef Kadlecsik <kadlec@...filter.org>,
 "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>, Nikolay Aleksandrov <razor@...ckwall.org>,
 netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v4 nf-next 0/2] flow offload teardown when layer 2 roaming

On 10/2/25 9:47 AM, Florian Westphal wrote:
> Eric Woudstra <ericwouds@...il.com> wrote:
>> This patch-set can be reviewed separately from my submissions concerning
>> the bridge-fastpath.
>>
>> In case of a bridge in the forward-fastpath or bridge-fastpath the fdb is
>> used to create the tuple. In case of roaming at layer 2 level, for example
>> 802.11r, the destination device is changed in the fdb.
>                ~~~~~~~~~~~~~~~~~~
> 
> destination device == output port to use for xmit?
> 

Indeed. It is the bridge-port that is being changed for the same
combination of vid and address. In the tuple it is the output port for xmit.

>> The destination
>> device of a direct transmitting tuple is no longer valid and traffic is
>> send to the wrong destination. Also the hardware offloaded fastpath is not
>> valid anymore.
> 
> Can you outline/summarize the existing behaviour for sw bridge, without
> flowtable offload being in the mix here?
> 
> What is the existing behaviour without flowtable but bridge hw offload in place?
> What mechanism corrects the output port in these cases?
> 

What is comes down to is br_fdb_update(), when an existing fdb entry is
found for the vid/address combination. When it appears on a different
bridge port then stored in the fdb entry, the fdb entry is modified.

Also br_switchdev_fdb_notify(br, fdb, RTM_DELNEIGH) is called so that
drivers can remove bridge hw offload. This is what I also want to listen
for, as it is the only message that holds to old bridge-port.

Listening in particular when it is called from br_fdb_update(), but it
can be debated if we should respond to all of these calls, or only when
called from br_fdb_update(). If we want to narrow it down, may need to
add an "updating" flag to:

struct switchdev_notifier_fdb_info {
	struct switchdev_notifier_info info; /* must be first */
	const unsigned char *addr;
	u16 vid;
	u8 added_by_user:1,
	   is_local:1,
	   locked:1,
	   offloaded:1;
+	   updating:1;
};

Or something similar.

>> This flowentry needs to be torn down asap.
> 
>> Changes in v4:
>> - Removed patch "don't follow fastpath when marked teardown".
>> - Use a work queue to process the event.
> 
> Full walk of flowtable is expensive, how many events
> are expected to be generated?
> 
> Having a few thousands of fdb updates trigger one flowtable
> walk each seems like a non-starter?

Indeed, this would be an argument to narrow it down. Fully walking
through the flowtable, only when an fdb entry's bridge-port is being
updated.