diff options
| author | Daniel Müller <deso@posteo.net> | 2022-07-27 21:29:55 +0300 |
|---|---|---|
| committer | Andrii Nakryiko <andrii@kernel.org> | 2022-07-29 21:10:01 +0300 |
| commit | 639de43ef0dda165441af400ecb372e16b7f9354 (patch) | |
| tree | aa486fc9c32efcddd0e402e24d674a8c549e6be0 /kernel | |
| parent | a6df06744b2d0b953615e0d6ca8b5e84ae4019fc (diff) | |
| download | linux-639de43ef0dda165441af400ecb372e16b7f9354.tar.xz | |
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
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions