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

[Konstantin Khorenko <khorenko@virtuozzo.com>]

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