[PATCH bpf-next] tools/testing/selftests/bpf/test_tc_tunnel.sh: Fix wait for server bind
Commit f803bcf9208a ("selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh") added code that waits for the netcat server to start before the netcat client attempts to connect to it. However, not all calls to 'server_listen' were guarded.
This patch adds the existing 'wait_for_port' guard after the remaining call to 'server_listen'.
Fixes: f803bcf9208a ("selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh") Signed-off-by: Marco Leogrande leogrande@google.com --- tools/testing/selftests/bpf/test_tc_tunnel.sh | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/bpf/test_tc_tunnel.sh b/tools/testing/selftests/bpf/test_tc_tunnel.sh index 7989ec6084545..cb55a908bb0d7 100755 --- a/tools/testing/selftests/bpf/test_tc_tunnel.sh +++ b/tools/testing/selftests/bpf/test_tc_tunnel.sh @@ -305,6 +305,7 @@ else client_connect verify_data server_listen + wait_for_port ${port} ${netcat_opt} fi
# serverside, use BPF for decap
On 12/02, Marco Leogrande wrote:
Commit f803bcf9208a ("selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh") added code that waits for the netcat server to start before the netcat client attempts to connect to it. However, not all calls to 'server_listen' were guarded.
This patch adds the existing 'wait_for_port' guard after the remaining call to 'server_listen'.
Fixes: f803bcf9208a ("selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh") Signed-off-by: Marco Leogrande leogrande@google.com
tools/testing/selftests/bpf/test_tc_tunnel.sh | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/bpf/test_tc_tunnel.sh b/tools/testing/selftests/bpf/test_tc_tunnel.sh index 7989ec6084545..cb55a908bb0d7 100755 --- a/tools/testing/selftests/bpf/test_tc_tunnel.sh +++ b/tools/testing/selftests/bpf/test_tc_tunnel.sh @@ -305,6 +305,7 @@ else client_connect verify_data server_listen
- wait_for_port ${port} ${netcat_opt}
fi
# serverside, use BPF for decap
2.47.0.338.g60cca15819-goog
Do you see this failing in your CI or in the BPF CI? It seems ok to add wait_for_port here, but the likelihood of the issue seems minuscule. There is a bunch of ip/tc/etc calls between this server_listen and the next client_connect (and I'd be surprised to hear that netcat is still not listening by the time we reach next client_connect).
On Mon, Dec 2, 2024 at 4:15 PM Stanislav Fomichev stfomichev@gmail.com wrote:
Do you see this failing in your CI or in the BPF CI?
I see this failing in our internal CI, in around 1% to 2% of the CI runs.
It seems ok to add wait_for_port here, but the likelihood of the issue seems minuscule. There is a bunch of ip/tc/etc calls between this server_listen and the next client_connect (and I'd be surprised to hear that netcat is still not listening by the time we reach next client_connect).
I'm surprised as well, and I've not found a good correlation with the root cause of the delayed server start, besides generic "slowness".
You also make a good point - by calling wait_for_port this early we "waste" the opportunity to run the other ip commands in parallel in the meantime. I had considered moving this wait down, just before the next client_connect, but I concluded it might be less readable since it would be so distant from the server_listen it pairs with. But I can make that change if it seems better.
On 12/03, Marco Leogrande wrote:
On Mon, Dec 2, 2024 at 4:15 PM Stanislav Fomichev stfomichev@gmail.com wrote:
Do you see this failing in your CI or in the BPF CI?
I see this failing in our internal CI, in around 1% to 2% of the CI runs.
It seems ok to add wait_for_port here, but the likelihood of the issue seems minuscule. There is a bunch of ip/tc/etc calls between this server_listen and the next client_connect (and I'd be surprised to hear that netcat is still not listening by the time we reach next client_connect).
I'm surprised as well, and I've not found a good correlation with the root cause of the delayed server start, besides generic "slowness".
You also make a good point - by calling wait_for_port this early we "waste" the opportunity to run the other ip commands in parallel in the meantime. I had considered moving this wait down, just before the next client_connect, but I concluded it might be less readable since it would be so distant from the server_listen it pairs with. But I can make that change if it seems better.
Thanks for the details, let's keep as is.
Acked-by: Stanislav Fomichev sdf@fomichev.me
Hello:
This patch was applied to bpf/bpf-next.git (master) by Alexei Starovoitov ast@kernel.org:
On Mon, 2 Dec 2024 12:45:30 -0800 you wrote:
Commit f803bcf9208a ("selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh") added code that waits for the netcat server to start before the netcat client attempts to connect to it. However, not all calls to 'server_listen' were guarded.
This patch adds the existing 'wait_for_port' guard after the remaining call to 'server_listen'.
[...]
Here is the summary with links: - [bpf-next] tools/testing/selftests/bpf/test_tc_tunnel.sh: Fix wait for server bind https://git.kernel.org/bpf/bpf-next/c/e2f0791124a1
You are awesome, thank you!
linux-kselftest-mirror@lists.linaro.org
-
Marco Leogrande -
patchwork-bot+netdevbpf＠kernel.org -
Stanislav Fomichev