[PATCH 2/2] tests/threads-execve: force clock_nanosleep syscall

[Alyssa Ross]

Using clock_nanosleep here means that these sleeps won't show up in
the test result, which only monitors for nanosleep.  But on Musl,
clock_nanosleep(CLOCK_REALTIME, 0, ...) will use the nanosleep
syscall, so on Musl these extra sleeps would appear in the test output
and break the tests.
---
As an aside, by default if they fail, threads-execve* tests will be
rerun repeatedly for 1.2 hours, in the hope that they will pass.  It
makes sense to rerun them a few times, since the result might be out
of order, but running them thousands of times is overkill, and made it
difficult for me to figure out what was going on -- for a while I
thought they were just very slow.

Is there a reason for the default timeout being so high?  And/or
perhaps there could be a maximum number of retries for
threads-execve*, in addition to the timeout?

 tests/threads-execve.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/threads-execve.c b/tests/threads-execve.c
index 7004f02b..8613c7cf 100644
--- a/tests/threads-execve.c
+++ b/tests/threads-execve.c
@@ -120,7 +120,7 @@ thread(void *arg)
 		perror_msg_and_fail("execve");
 
 	struct timespec ts = { .tv_nsec = 100000000 };
-	(void) clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);
+	(void) syscall(__NR_clock_nanosleep, CLOCK_REALTIME, 0, &ts, NULL);
 
 	kernel_old_timespec_t ots = { .tv_nsec = 12345 };
 	printf("%-5d nanosleep({tv_sec=0, tv_nsec=%u}, NULL) = 0\n",
@@ -170,7 +170,7 @@ main(int ac, char **av)
 
 	if (ac < 3) {
 		struct timespec ts = { .tv_nsec = 1 };
-		if (clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL))
+		if (syscall(__NR_clock_nanosleep, CLOCK_REALTIME, 0, &ts, NULL))
 			perror_msg_and_skip("clock_nanosleep CLOCK_REALTIME");
 
 		get_sigsetsize();
-- 
2.31.0