selftests/bpf: Bump internal send_signal/send_signal_tracepoint timeout
authorDaniel Müller <deso@posteo.net>
Wed, 27 Jul 2022 18:29:55 +0000 (18:29 +0000)
committerAndrii Nakryiko <andrii@kernel.org>
Fri, 29 Jul 2022 18:10:01 +0000 (11:10 -0700)
commit639de43ef0dda165441af400ecb372e16b7f9354
treeaa486fc9c32efcddd0e402e24d674a8c549e6be0
parenta6df06744b2d0b953615e0d6ca8b5e84ae4019fc
selftests/bpf: Bump internal send_signal/send_signal_tracepoint timeout

The send_signal/send_signal_tracepoint is pretty flaky, with at least
one failure in every ten runs on a few attempts I've tried it:
  > test_send_signal_common:PASS:pipe_c2p 0 nsec
  > test_send_signal_common:PASS:pipe_p2c 0 nsec
  > test_send_signal_common:PASS:fork 0 nsec
  > test_send_signal_common:PASS:skel_open_and_load 0 nsec
  > test_send_signal_common:PASS:skel_attach 0 nsec
  > test_send_signal_common:PASS:pipe_read 0 nsec
  > test_send_signal_common:PASS:pipe_write 0 nsec
  > test_send_signal_common:PASS:reading pipe 0 nsec
  > test_send_signal_common:PASS:reading pipe error: size 0 0 nsec
  > test_send_signal_common:FAIL:incorrect result unexpected incorrect result: actual 48 != expected 50
  > test_send_signal_common:PASS:pipe_write 0 nsec
  > #139/1   send_signal/send_signal_tracepoint:FAIL

The reason does not appear to be a correctness issue in the strict
sense. Rather, we merely do not receive the signal we are waiting for
within the provided timeout.
Let's bump the timeout by a factor of ten. With that change I have not
been able to reproduce the failure in 150+ iterations. I am also sneaking
in a small simplification to the test_progs test selection logic.

Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20220727182955.4044988-1-deso@posteo.net
tools/testing/selftests/bpf/prog_tests/send_signal.c
tools/testing/selftests/bpf/test_progs.c