From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Palethorpe Date: Thu, 11 Feb 2021 15:07:15 +0000 Subject: [LTP] [PATCH 4/5] API: Add tst_clone In-Reply-To: References: <20210211110317.31942-1-rpalethorpe@suse.com> <20210211110317.31942-5-rpalethorpe@suse.com> <877dne65s5.fsf@suse.de> Message-ID: <874kii63to.fsf@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it Hello, Cyril Hrubis 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 #include #include 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.