diff mbox series

[RFC,net-next,(resend),1/4] net: bridge: respect sticky flag on external learn

Message ID 20241108035546.2055996-2-elliot.ayrey@alliedtelesis.co.nz (mailing list archive)
State RFC
Delegated to: Netdev Maintainers
Headers show
Series Send notifications for roaming hosts | expand

Checks

Context Check Description
netdev/series_format success Posting correctly formatted
netdev/tree_selection success Clearly marked for net-next
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 3 this patch: 3
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers success CCed 8 of 8 maintainers
netdev/build_clang success Errors and warnings before: 3 this patch: 3
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 4 this patch: 4
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 9 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Elliot Ayrey Nov. 8, 2024, 3:55 a.m. UTC
The fdb sticky flag is used to stop a host from roaming to another
port. However upon receiving a switchdev notification to update an fdb
entry the sticky flag is not respected and as long as the new entry is
not locked the host will be allowed to roam to the new port.

Fix this by considering the sticky flag before allowing an externally
learned host to roam.

Signed-off-by: Elliot Ayrey <elliot.ayrey@alliedtelesis.co.nz>
---
 net/bridge/br_fdb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Elliot Ayrey Nov. 24, 2024, 9:01 p.m. UTC | #1
On Sat, 2024-11-09 at 15:32 +0200, Nikolay Aleksandrov wrote:
> So you have a sticky fdb entry added, but it is still allowed to roam
> in HW?

No the hardware has informed us a host has _tried_ to roam.

As I think about this more, using the sticky bit alone probably isn't
the best idea and it might be better if this mechanism were related to
a port being locked? After all the port being locked in hardware is
what generates this event.
Nikolay Aleksandrov Nov. 24, 2024, 10:01 p.m. UTC | #2
On 24/11/2024 23:01, Elliot Ayrey wrote:
> On Sat, 2024-11-09 at 15:32 +0200, Nikolay Aleksandrov wrote:
>> So you have a sticky fdb entry added, but it is still allowed to roam
>> in HW?
> 
> No the hardware has informed us a host has _tried_ to roam.
> 
> As I think about this more, using the sticky bit alone probably isn't
> the best idea and it might be better if this mechanism were related to
> a port being locked? After all the port being locked in hardware is
> what generates this event.

That does sound better, but we should have the same functionality
in software as well. Perhaps optional to avoid potential flood of
current users with unexpected notifications, see my response to
the other mail for more info.

Cheers,
 Nik
diff mbox series

Patch

diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 1cd7bade9b3b..72663ca824d3 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -1457,7 +1457,8 @@  int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
 
 		fdb->updated = jiffies;
 
-		if (READ_ONCE(fdb->dst) != p) {
+		if (READ_ONCE(fdb->dst) != p &&
+		    !test_bit(BR_FDB_STICKY, &fdb->flags)) {
 			WRITE_ONCE(fdb->dst, p);
 			modified = true;
 		}