From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2 1/2] syscalls/pidfd_open01.c: Add check for close-on-exec flag
Date: Wed, 13 May 2020 11:20:28 +0200 [thread overview]
Message-ID: <20200513092028.GA4598@dell5510> (raw)
In-Reply-To: <5EBB5B3D.4020302@cn.fujitsu.com>
Hi Yang,
> For the patch set, I and Viresh have the following doubts so do you have any
> suggestion about them?
> 1) I keep TEST() in pidfd_open01/pidfd_open03 for now but I think it is
> surplus because pidfd/fd and TERRNO are enough to check return value
> and errno.
> I wonder if it is necessary to keep TEST()?
yes, I've noticed your discussion at v1, sorry I wasn't able to follow.
https://patchwork.ozlabs.org/project/ltp/patch/20200430085742.1663-1-yangx.jy@cn.fujitsu.com/
Just to get context, We're talking about part of the changes between v1 and v2:
+++ b/testcases/kernel/syscalls/pidfd_open/pidfd_open03.c
@@ -27,9 +27,11 @@ static void run(void)
exit(EXIT_SUCCESS);
}
- fd = pidfd_open(pid, 0);
+ TEST(pidfd_open(pid, 0));
+
+ fd = TST_RET;
if (fd == -1)
- tst_brk(TFAIL | TERRNO, "pidfd_open() failed");
+ tst_brk(TFAIL | TTERRNO, "pidfd_open() failed");
TST_CHECKPOINT_WAKE(0);
I haven't found Cyril's request to use TEST(). To be honest, not sure if it was
meant to make sure that errno needs to be reset before (which TEST()) does.
If not, using pidfd_open() directly would be ok for me.
> 2) tst_syscall() is enough to check the support of pidfd_open() and I
> don't want to define check function as fsopen_supported_by_kernel()
> does.
> Do you think so?
> BTW:
> I don't like the implementation of fsopen_supported_by_kernel():
> a) syscall()/tst_syscall() is enough to check the support of
> pidfd_open(2) and 'tst_kvercmp(5, 2, 0)) < 0' will skip the check if
+1 for tst_syscall()
> a kernel on distribution is newer than v5.2 but drop the support of
> pidfd_open(2) on purpose.
"drop support of pidfd_open(2) on purpose": would anybody has a reason to do
that?
> b) tst_syscall() has checked ENOSYS error so we can simple
> fsopen_supported_by_kernel() by replacing syscall() with tst_syscalls().
Well, one of the benefits of fsopen_supported_by_kernel() was to reduce a bit of
duplicity. Even if the implementation is like TEST and SAFE_CLOSE(), it's
a fewer lines (+ function name as a self docs).
void fsopen_supported_by_kernel(void)
{
TEST(tst_syscall(__NR_fsopen, NULL, 0));
if (TST_RET != -1)
SAFE_CLOSE(TST_RET);
}
For your change for pidfd_open03.c:
static void setup(void)
{
int pidfd = -1;
// Check if pidfd_open(2) is not supported
pidfd = tst_syscall(__NR_pidfd_open, getpid(), 0);
if (pidfd != -1)
SAFE_CLOSE(pidfd);
}
static struct tst_test test = {
- .min_kver = "5.3",
+ .setup = setup,
How about to call the function pidfd_open_supported_by_kernel()?
Than you can remove the comment (which BTW should use C style /* */).
And IMHO you don't have to assign pidfd to -1.
Kind regards,
Petr
next prev parent reply other threads:[~2020-05-13 9:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 1:26 [LTP] [PATCH v2 1/2] syscalls/pidfd_open01.c: Add check for close-on-exec flag Xiao Yang
2020-05-13 1:26 ` [LTP] [PATCH v2 2/2] syscalls/pidfd_open*.c: Drop .min_kver flag Xiao Yang
2020-05-13 5:55 ` Viresh Kumar
2020-05-13 6:03 ` Xiao Yang
2020-05-13 6:13 ` Viresh Kumar
2020-05-13 6:31 ` Xiao Yang
2020-05-13 6:39 ` Viresh Kumar
2020-05-13 2:28 ` [LTP] [PATCH v2 1/2] syscalls/pidfd_open01.c: Add check for close-on-exec flag Xiao Yang
2020-05-13 9:20 ` Petr Vorel [this message]
2020-05-13 10:21 ` Xiao Yang
2020-05-13 10:30 ` Petr Vorel
2020-05-14 7:37 ` Petr Vorel
2020-05-14 9:43 ` Xiao Yang
2020-05-14 14:14 ` Petr Vorel
2020-05-14 14:27 ` Xiao Yang
2020-05-13 12:34 ` Cyril Hrubis
2020-05-13 13:12 ` Xiao Yang
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=20200513092028.GA4598@dell5510 \
--to=pvorel@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