639de43ef0
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