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

[Dmitry V. Levin]

On Tue, May 04, 2021 at 05:57:43PM +0000, Alyssa Ross wrote:
> 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

There is an environment variable TIMEOUT_DURATION that controls how long
each test is allowed to run.  It's default value is 1500 (seconds), and
it's implemented using timeout(1).  Please make sure your environment
provides timeout(1), otherwise TIMEOUT_DURATION has no effect.

[...]
> --- 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);

The use of __NR_clock_nanosleep is somewhat problematic since modern
32-bit architectures do not have it defined (they use
__NR_clock_nanosleep_time64 instead), see strace commit v5.6~160.

One might argue, however, that all these architectures also do not have
__NR_nanosleep defined so the test is skipped.  This is technically
correct, the use of __NR_nanosleep is a known weakness of the
implementation which needs to distinguish between two kinds of sleep.

Therefore, it should be safe to apply the patch as is.


-- 
ldv