[LTP] [PATCH 4/5] API: Add tst_clone

[Richard Palethorpe <rpalethorpe@suse.de>]

Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
>> >> +	int flags;
>> >> +	pid_t pid = -1;
>> >> +
>> >> +	tst_flush();
>> >> +
>> >> +	errno = ENOSYS;
>> >> +	if (__NR_clone3 != __LTP__NR_INVALID_SYSCALL)
>> >> +		pid = syscall(__NR_clone3, &args, sizeof(args));
>> >> +
>> >> +	if (pid == -1 && errno != ENOSYS)
>> >> +		return -1;
>> >
>> > As far as I can tell when kernel is too old we would get EINVAL because
>> > the syscall number is not allocated. ENOSYS happens mostly when syscall
>> > number is allocated and kernel does not implement the functionality,
>> > e.g. it's disabled in .config.
>> >
>> > I wonder if it's even menaningful to handle ENOSYS here, I doubt that
>> > clone3() can be disabled, or do I miss something?
>> 
>> AFAICT it should return ENOSYS if the syscall number is greater than the
>> current maximum. This is certainly true for riscv and also apears to be
>> true for arm64 and x86. It is also written in a kernel book I have from
>> 2010 :-p
>
> Sounds sane, so we get EINVAL if the syscall number is out of the
> syscall table. So I guess that we have to handle both.

I don't know where you are getting EINVAL from?

Try the following

#include <errno.h>
#include <unistd.h>
#include <sys/syscall.h>

int main(int argc, const char* argv[])
{
	syscall(~0ULL);

	return errno;
}

It returns ENOSYS and strace shows this is not due to any sanity
checking by glibc.

I guess it would actually be a bug if it returned EINVAL although I am
not sure this is specified anywhere.

-- 
Thank you,
Richard.