From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 4/5] API: Add tst_clone
Date: Thu, 11 Feb 2021 15:35:46 +0100 [thread overview]
Message-ID: <YCVAwoQDKJWMi6hX@rei.lan> (raw)
In-Reply-To: <877dne65s5.fsf@suse.de>
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.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2021-02-11 14:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 11:03 [LTP] [PATCH 0/5] Add close_range01, SAFE_DUP2 and SAFE_CLONE Richard Palethorpe
2021-02-11 11:03 ` [LTP] [PATCH 1/5] close_range: Add syscall number Richard Palethorpe
2021-02-11 11:03 ` [LTP] [PATCH 2/5] API: Add SAFE_DUP2 Richard Palethorpe
2021-02-11 11:03 ` [LTP] [PATCH 3/5] API: Fix clone.h Richard Palethorpe
2021-02-11 11:03 ` [LTP] [PATCH 4/5] API: Add tst_clone Richard Palethorpe
2021-02-11 12:51 ` Cyril Hrubis
2021-02-11 14:24 ` Richard Palethorpe
2021-02-11 14:35 ` Cyril Hrubis [this message]
2021-02-11 15:07 ` Richard Palethorpe
2021-02-11 15:30 ` Cyril Hrubis
2021-02-11 11:03 ` [LTP] [PATCH 5/5] close_range: Add test Richard Palethorpe
2021-02-11 12:54 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YCVAwoQDKJWMi6hX@rei.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox