[Devel] [PATCH hci-8.1] selftests: forwarding: flush neighbours in the bridge locked port test

[Devel] [PATCH hci-8.1] selftests: forwarding: flush neighbours in the bridge locked port test

[Eva Kurchatova]

While the port drops h1's traffic, h1's neighbour entry for h2 can go
stale and start probes that the port drops too. If that resolution
fails just after the port lets h1's traffic through again, the next
ping gets "Destination Host Unreachable", ping stops at the first
error because a deadline is set, and the test fails with, for example,
"Ping did not work after replacing FDB entry".

Flush h1's neighbours once the port passes its traffic again, so that
the next ping starts a fresh resolution.

Fixes: b2b681a41251 ("selftests: forwarding: tests of locked port feature")
Fixes: 4a331d346996 ("selftests: forwarding: Add MAC Authentication Bypass (MAB) test cases")
https://virtuozzo.atlassian.net/browse/VSTOR-153057
Feature: fix selftests

Signed-off-by: Eva Kurchatova <eva.kurchatova@virtuozzo.com>
---
 tools/testing/selftests/net/forwarding/bridge_locked_port.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/testing/selftests/net/forwarding/bridge_locked_port.sh b/tools/testing/selftests/net/forwarding/bridge_locked_port.sh
index c62331b2e006..461f598638c2 100755
--- a/tools/testing/selftests/net/forwarding/bridge_locked_port.sh
+++ b/tools/testing/selftests/net/forwarding/bridge_locked_port.sh
@@ -105,6 +105,7 @@ locked_port_ipv4()
 	check_fail $? "Ping worked after locking port, but before adding FDB entry"
 
 	bridge fdb add `mac_get $h1` dev $swp1 master static
+	ip neigh flush dev $h1
 
 	ping_do $h1 192.0.2.2
 	check_err $? "Ping did not work after locking port and adding FDB entry"
@@ -135,6 +136,7 @@ locked_port_vlan()
 	check_fail $? "Ping through vlan worked after locking port, but before adding FDB entry"
 
 	bridge fdb add `mac_get $h1` dev $swp1 vlan 100 master static
+	ip neigh flush dev $h1.100
 
 	ping_do $h1.100 198.51.100.2
 	check_err $? "Ping through vlan did not work after locking port and adding FDB entry"
@@ -164,6 +166,7 @@ locked_port_ipv6()
 	check_fail $? "Ping6 worked after locking port, but before adding FDB entry"
 
 	bridge fdb add `mac_get $h1` dev $swp1 master static
+	ip neigh flush dev $h1
 	ping6_do $h1 2001:db8:1::2
 	check_err $? "Ping6 did not work after locking port and adding FDB entry"
 
@@ -201,6 +204,7 @@ locked_port_mab()
 	check_err $? "Locked FDB entry not created"
 
 	bridge fdb replace `mac_get $h1` dev $swp1 master static
+	ip neigh flush dev $h1
 
 	ping_do $h1 192.0.2.2
 	check_err $? "Ping did not work after replacing FDB entry"
-- 
2.56.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1] selftests: forwarding: flush neighbours in the bridge locked port test

[no-reply]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] selftests: commit message carries downstream-only Jira URL and Feature tag
--

commit 5c88239541683d62eb566e440a6cf1b940bf6161
Author: Eva Kurchatova <eva.kurchatova@virtuozzo.com>

selftests: forwarding: flush neighbours in the bridge locked port test

This patch adds "ip neigh flush" calls in bridge_locked_port.sh. Each call
runs right after the FDB entry is added or replaced, so the next ping starts
a fresh neighbour resolution instead of failing on a stale entry.

> selftests: forwarding: flush neighbours in the bridge locked port test
>
> [ ... ]
>
>     Fixes: b2b681a41251 ("selftests: forwarding: tests of locked port feature")
>     Fixes: 4a331d346996 ("selftests: forwarding: Add MAC Authentication Bypass (MAB) test cases")
>     https://virtuozzo.atlassian.net/browse/VSTOR-153057
>     Feature: fix selftests
>
>     Signed-off-by: Eva Kurchatova <eva.kurchatova@virtuozzo.com>

[Severity: Low]
This isn't a bug in the code, but the commit message has two downstream-only
lines:

https://virtuozzo.atlassian.net/browse/VSTOR-153057
Feature: fix selftests

Upstream reviewers can't open the Jira URL, and "Feature:" isn't a
recognised kernel trailer. Could both lines be dropped before this goes to
netdev or linux-kselftest?

The change in bridge_locked_port.sh looks fine. In each test the flush comes
right after the "bridge fdb add" or "bridge fdb replace", before the ping
that must succeed. The device it flushes (h1, or h1.100 in the VLAN test) is
the same one the ping uses.

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261103021237.2465704-1-eva.kurchatova@virtuozzo.com?part=1

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1] selftests: forwarding: flush neighbours in the bridge locked port test

[Eva Kurchatova (Virtuozzo)]

On 11/3/26 04:15, no-reply@sashiko.virtuozzo.com wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] selftests: commit message carries downstream-only Jira URL and Feature tag
> --
>
> commit 5c88239541683d62eb566e440a6cf1b940bf6161
> Author: Eva Kurchatova <eva.kurchatova@virtuozzo.com>
>
> selftests: forwarding: flush neighbours in the bridge locked port test
>
> This patch adds "ip neigh flush" calls in bridge_locked_port.sh. Each call
> runs right after the FDB entry is added or replaced, so the next ping starts
> a fresh neighbour resolution instead of failing on a stale entry.
>
>> selftests: forwarding: flush neighbours in the bridge locked port test
>>
>> [ ... ]
>>
>>      Fixes: b2b681a41251 ("selftests: forwarding: tests of locked port feature")
>>      Fixes: 4a331d346996 ("selftests: forwarding: Add MAC Authentication Bypass (MAB) test cases")
>>      https://virtuozzo.atlassian.net/browse/VSTOR-153057
>>      Feature: fix selftests
>>
>>      Signed-off-by: Eva Kurchatova <eva.kurchatova@virtuozzo.com>
> [Severity: Low]
> This isn't a bug in the code, but the commit message has two downstream-only
> lines:
>
> https://virtuozzo.atlassian.net/browse/VSTOR-153057
> Feature: fix selftests
>
> Upstream reviewers can't open the Jira URL, and "Feature:" isn't a
> recognised kernel trailer. Could both lines be dropped before this goes to
> netdev or linux-kselftest?

Indeed, but this is a Virtuozzo mailing list, and all patches have these 
downstream lines by design. Do we have a way to make Sashiko understand 
this from the get-go in future?

> The change in bridge_locked_port.sh looks fine. In each test the flush comes
> right after the "bridge fdb add" or "bridge fdb replace", before the ping
> that must succeed. The device it flushes (h1, or h1.100 in the VLAN test) is
> the same one the ping uses.
>
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1] selftests: forwarding: flush neighbours in the bridge locked port test

[Konstantin Khorenko]

On Tue, 03 Nov 2026 04:12:34 +0200, Eva Kurchatova wrote:
> While the port drops h1's traffic, h1's neighbour entry for h2 can go
> stale and start probes that the port drops too. If that resolution
> fails just after the port lets h1's traffic through again, the next
> ping gets "Destination Host Unreachable", ping stops at the first
> error because a deadline is set, and the test fails with, for example,
> "Ping did not work after replacing FDB entry".

Only locked_port_mab can fail this way, and the CI log shows only that
case failing. So please:

- keep only the flush in locked_port_mab and drop the other three;
- keep only "Fixes: 4a331d346996", b2b681a41251 goes with the dropped
  hunks;
- describe the resolution that actually fails (below).

Why only MAB: its entry for 192.0.2.2 is left over from
locked_port_ipv4, and the port stays locked for two pings, long enough
for that entry to time out. In the other three cases the first ping
resolves a fresh entry, which stays REACHABLE longer than the port is
locked. The ipv6 flush would even hide the MAB failure: it also removes
the old IPv4 entry before the MAB case runs.

What fails: the stale entry's unicast probes failing reports nothing.
The error comes from the broadcast resolution that the locked ping
starts. It fails after the next ping has queued its first packet, and
that ping gets "Destination Host Unreachable".

Nit: say "the locked bridge port" in the first sentence, and name the
MAB check instead of "for example".

-- 
Konstantin Khorenko,
Virtuozzo Linux Kernel Team

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel