In some conditions, background processes in udpgro don't have enough
time to set up the sockets. When foreground processes start, this
results in the bad GRO lookup test freezing or reporting that it
received 0 gro segments.
To fix this, increase the time given to background processes to complete
the startup before foreground processes start.
This is the same issue and the same fix as posted by Adrien Therry.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Lucas Karpinski <[email protected]>
---
tools/testing/selftests/net/udpgro.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/udpgro.sh b/tools/testing/selftests/net/udpgro.sh
index 0c743752669a..4ccbcb2390ad 100755
--- a/tools/testing/selftests/net/udpgro.sh
+++ b/tools/testing/selftests/net/udpgro.sh
@@ -97,7 +97,8 @@ run_one_nat() {
echo "ok" || \
echo "failed"&
- sleep 0.1
+ # Hack: let bg programs complete the startup
+ sleep 0.2
./udpgso_bench_tx ${tx_args}
ret=$?
kill -INT $pid
--
2.41.0
On Mon, 23 Oct 2023 15:50:33 -0400 Lucas Karpinski wrote:
> This is the same issue and the same fix as posted by Adrien Therry.
> Link: https://lore.kernel.org/all/[email protected]/
Let's not let the hacks spread.
We suggested two options in the linked thread.
Another one is to explicitly rendezvous the processes - have both sides
exchange a UDP packet or establish a TCP connection after setting up.