public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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

  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