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

Elliot Ayrey posted 4 patches 2 weeks, 5 days ago
[RFC net-next (resend) 1/4] net: bridge: respect sticky flag on external learn
Posted by Elliot Ayrey 2 weeks, 5 days ago
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(-)

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;
 		}
Re: [RFC net-next (resend) 1/4] net: bridge: respect sticky flag on external learn
Posted by Elliot Ayrey 2 days, 22 hours ago
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.
Re: [RFC net-next (resend) 1/4] net: bridge: respect sticky flag on external learn
Posted by Nikolay Aleksandrov 2 days, 21 hours ago
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