Re: [PATCH bpf-next] selftests/bpf: fix usleep() implementation

On Thu, Mar 12, 2020 at 11:45 PM Alexei Starovoitov
[off-list ref] wrote:

On Thu, Mar 12, 2020 at 11:18:37PM -0700, Andrii Nakryiko wrote:

quoted

nanosleep syscall expects pointer to struct timespec, not nanoseconds
directly. Current implementation fulfills its purpose of invoking nanosleep
syscall, but doesn't really provide sleeping capabilities, which can cause
flakiness for tests relying on usleep() to wait for something.

Fixes: ec12a57b822c ("selftests/bpf: Guarantee that useep() calls nanosleep() syscall")
Signed-off-by: Andrii Nakryiko <redacted>
---
 tools/testing/selftests/bpf/test_progs.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
index 2b0bc1171c9c..b6201dd82edf 100644
--- a/tools/testing/selftests/bpf/test_progs.c
+++ b/tools/testing/selftests/bpf/test_progs.c

@@ -35,7 +35,16 @@ struct prog_test_def {
  */
 int usleep(useconds_t usec)
 {
-     return syscall(__NR_nanosleep, usec * 1000UL);
+     struct timespec ts;
+
+     if (usec > 999999) {
+             ts.tv_sec = usec / 1000000;
+             ts.tv_nsec = usec % 1000000;
+     } else {
+             ts.tv_sec = 0;
+             ts.tv_nsec = usec;
+     }
+     return nanosleep(&ts, NULL);
 }

Is this a copy-paste from somewhere?

nope, my very own prematurely optimized implementation :)

Above 'if' looks like premature optimization.
I applied it anyway, since it fixes flakiness in test_progs -n 24.
Now pin*tp* tests are stable.

Great, I hoped as much.

But the other one is still flaky:
server_thread:FAIL:237
Failed to accept client: Resource temporarily unavailable
#64 tcp_rtt:FAIL
Note that if I run the test alone (test_progs -n 64) it is stable.
It fails only when run as part of bigger test_progs.
test_progs -n 30-64 sporadically fails (most of the time)
test_progs -n 40-64 consistently passes
Haven't bisected further.

Okey, I'll get to it once I'm done fixing a bunch of other problems.
Seems like tcp_rtt needs some more love, sigh... :(