On 9/24/25 8:38 PM, Mike Pattrick via dev wrote: > On Sun, Sep 14, 2025 at 8:51 PM Ihar Hrachyshka <[email protected]> > wrote: > >> The test failure occurs quite consistently (~50% of the runs) when using >> a musl static build. It always happens if I add `sync` or `sleep` before >> vswitchd shutdown. The warning message can be seen in the >> retained vswitchd log (-d) even when the test case passes. >> >> I believe a race condition between vswitchd flushing the log to disc and >> the test code reading from the log file explains why the test case >> doesn't fail consistently. >> >> Signed-off-by: Ihar Hrachyshka <[email protected]> >> --- >> tests/tunnel.at | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tests/tunnel.at b/tests/tunnel.at >> index f6be3f345..cebd392ca 100644 >> --- a/tests/tunnel.at >> +++ b/tests/tunnel.at >> @@ -129,7 +129,7 @@ AT_CHECK([ovs-appctl dpctl/dump-flows | tail -1], [0], >> [dnl >> recirc_id(0),tunnel(src= >> 3.3.3.200/255.255.255.0,dst=1.1.1.1,ttl=64,tp_src=1,tp_dst=123),in_port(1),eth(),eth_type(0x0800), >> packets:0, bytes:0, used:never, actions:2 >> ]) >> >> -OVS_VSWITCHD_STOP >> +OVS_VSWITCHD_STOP(["/receive tunnel port not found/d"]) >> > > This actually might be a true bug. It can be reproduced with glibc just by > adding a sleep after the last dump-flows. I debugged it a little bit and > found that the tunnel map had a single entry with ip_dst = 1.1.1.1, but the > call to tnl_find that's failing is looking for an entry with dst=3.3.3.200. > I didn't look into it too deeply, but it doesn't seem like a MUSL related > issue to me or false positive.
The test itself is not well-made. As you mentioned, the flow that it is installing is for the opposite tunnel direction. It's also a GRE tunnel, but somehow L4 ports are specified. It's all a big mess. At the same time the tunnel code doesn't ever expect masked matches. The failure is definitely unrelated to MUSL. It's just that revalidation cannot actually pass on this flow. So, if the test can't finish before revalidation kicks in, we get a warning in the log as such a datapath flow is not valid. We can probably clean this all up, but we can't make the test race-free without disabling revalidators, which is a dangerous operation. So, we may as well just filter out the warning for now. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
