From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/execveat01: new test to verify execveat unlinked fd
Date: Mon, 30 Jul 2018 12:44:30 +0200 [thread overview]
Message-ID: <20180730104429.GD5149@rei> (raw)
In-Reply-To: <CALLuPvpvAoM=roZjv85-fLCh=Bz7zomcwB9qXH7-BSNtUihtVA@mail.gmail.com>
Hi!
> >> +static void do_child(void)
> >> +{
> >> +
> >> + char path[PATH_MAX];
> >> + char *argv[2] = {TEST_APP, NULL};
> >> + int fd;
> >> +
> >> + if (tst_get_path(TEST_APP, path, sizeof(path))) {
> >> + tst_brk(TBROK | TERRNO,
> >> + "Couldn't found "TEST_APP" binary in $PATH");
> >> + }
> >> + SAFE_CP(path, TEST_FILE_PATH);
> >
> > We do have a better API for this, have a look at creat07.c
>
> Could you have more detail guide on this? ie. copy TEST_APP to
> ovl mount path
If you specify the child executable as a resource file as in:
https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines#2222-datafiles
It will be compied to the test temporary directory before the test is
executed, then you can SAFE_CP() the file when you need it.
Alternatively I can also change the resource file mechanims in the test
library so that we can pass destionation there as well or export the
TST_RESOURCE_COPY() macro to the new library. Then you can use it to
copy the file into its final destination.
> >> + fd = SAFE_OPEN(TEST_FILE_PATH, O_PATH);
> >> + SAFE_UNLINK(TEST_FILE_PATH);
> >> +
> >> + argv[0] = TEST_FILE_PATH;
> >> + TEST(execveat(fd, "", argv, NULL, AT_EMPTY_PATH));
> >> + if (TEST_ERRNO == ENOSYS) {
> >> + tst_brk(TCONF,
> >> + "execveat is not supported in this kernel.");
> >> + }
> >
> > I suppose that we should handle EINVAL here, I think that we will get
> > EINVAL rather than ENOSYS when kernel will not recognize __NR_execveat
>
> EINVAL is happened to be the same return code of this testcase is expecting --
> the regression introduced from 8db6c34f1dbc ("Introduce v3 namespaced
> file capabilities"), therefore I might need another way to test whether kernel
> recognize __NR_execveat, so that I can differentiate not recognize and the
> regression. Do you have suggestion on this?
We usually specify minimal kernel version for the testcase in the
tst_test structure in that case and the test is skipped automatically on
old kernels that do not have the execveat() syscall implemented.
> >> +int main(void)
> >> +{
> >> + printf("Hello World\n");
> >> + exit(0);
> >
> > You can print the TPASS message from here and the result will be
> > propagated to the parent program. You just need to call tst_reinit()
> > that will initialize the test library. See creat07_child.c.
>
> I change execveat_child.c as below and get errors as:
> tst_test.c:144: BROK: LTP_IPC_PATH is not defined
> tst_test.c:869: BROK: Test haven't reported results!
>
> I think the cause is execveat() doesn't pass environment variables
> to its child, but SAFE_EXECL in creat07.c does.
> Do you suggest pass LTP_IPC_PATH in execveat() to make
> tst_reinit() in execveat_child run properly, or something else?
Yes, the LTP_IPC_PATH has to be passed manually in this case so that the
library could be re-initialized.
> #define TST_NO_DEFAULT_MAIN
> #include "tst_test.h"
>
> int main()
> {
> tst_reinit();
> tst_res(TPASS, "execveat_child is lunched as expcted");
> return 0;
> }
>
> thanks,
> Eddie
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2018-07-30 10:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-27 7:58 [LTP] [PATCH] syscalls/execveat01: new test to verify execveat unlinked fd Eddie.Horng
2018-07-27 9:47 ` Cyril Hrubis
2018-07-30 9:41 ` Eddie Horng
2018-07-30 10:44 ` Cyril Hrubis [this message]
2018-07-31 6:46 ` Eddie Horng
2018-07-31 12:43 ` Cyril Hrubis
[not found] <1530523133.30361.41.camel@mtkswgap22>
2018-07-02 10:46 ` Amir Goldstein
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=20180730104429.GD5149@rei \
--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