All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] Test library API changes
Date: Fri, 12 Feb 2016 07:33:46 -0500 (EST)	[thread overview]
Message-ID: <116630920.20260383.1455280426104.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20160211160313.GA22877@rei.lan>



----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Thursday, 11 February, 2016 5:03:13 PM
> Subject: Re: [LTP] Test library API changes
> 
> Hi!
> I've redone the child handling and now it does:
> 
> * If test sets forks_child flag in test structure pipe is opened at the
>   start of the test which is used to propagate test results from a child
>   to parent

Hi,

I was thinking about mapping a piece of shared memory for "struct results",
then we wouldn't have to worry about how/when child terminates and how
big buffer for resutls we need.

And if it was always there, it is one less parameter (forks_child) user
needs to provide.

> 
> * Child processes are created via SAFE_FORK(), which flushes stdout,
>   just in case there is something there, checks for for fork() failure
>   and clears the result structure.
> 
> * After each test run (call to test() function), wait() is called until
>   it returns ECHILD.
> 
>   If child was succesfully waited(), pipe is examined and if it contains
>   test results, these are added to parent results.
> 
>   We look into the pipe after each sucessful wait() in order not to fill
>   up the pipe capacity with many children.
> 
> * If child calls tst_brk(), exit() with non-zero value is called which is
>   handled in parent wait() and the parent exits with tst_brk() as well.
> 
>   Techincaly any child that does not exit with 0 cause main test process
>   to report TCONF/TBROK.
> 
>   At the moment the tst_brk() semantics is to exit the whole test since
>   something unexpected happened. Which seems to be right course of
>   action since failing SAFE_MACRO() in child should really cause main
>   test process to exit.

We have tests that crash/kill child on purpose. As I recall some examples
are mprotect and oom tests.

These tests would need to wait for child themselves, since non-zero exit
code is expected and we don't want reap_children() to see them and stop
the test.

> 
>   So if tst_brk() stays as it is we would need to add another call that
>   can exit the child (would do the same action as returning from the
>   test() function, i.e. write results and do exit(0)).

Other notes:

write_result calls "exit(0);", and run_tests calls exit as well after
it calls write_result.

If we stay with pipe and write_result, can we use atexit() to call it?
That would allow child to exit anywhere with "exit()" instead of making
sure it returns all the way to run_tests function.

Regards,
Jan

> 
> The code is at the same place at:
> 
> https://github.com/metan-ucw/ltp
> 
> Few test/example programs:
> 
> https://github.com/metan-ucw/ltp/blob/master/lib/newlib_tests/test05.c
> https://github.com/metan-ucw/ltp/blob/master/lib/newlib_tests/test06.c
> https://github.com/metan-ucw/ltp/blob/master/lib/newlib_tests/test07.c
> 
> There are probably stil a few rough edges: children forked from
> children, waiting for rest of the children after one of them called
> tst_brk(), etc. But the basic functionality seems to work fine.
> 
> As usuall comments are welcome.
> 
> --
> Cyril Hrubis
> chrubis@suse.cz
> 

  reply	other threads:[~2016-02-12 12:33 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-05 11:11 [LTP] Test library API changes Cyril Hrubis
2016-01-07 13:01 ` Jan Stancek
2016-01-07 13:27   ` Cyril Hrubis
2016-02-04 10:56   ` Cyril Hrubis
2016-02-08 18:02     ` Cyril Hrubis
2016-02-09 16:43       ` Cyril Hrubis
2016-02-09 16:57         ` Cyril Hrubis
2016-02-09 17:46           ` Cyril Hrubis
2016-02-10 10:42             ` Jan Stancek
2016-02-10 10:56               ` Cyril Hrubis
2016-02-10 11:41               ` Cyril Hrubis
2016-02-11 16:03                 ` Cyril Hrubis
2016-02-12 12:33                   ` Jan Stancek [this message]
2016-02-12 17:53                     ` Cyril Hrubis
2016-02-16 21:19                       ` Cyril Hrubis
2016-02-17 14:39                         ` Jan Stancek
2016-02-17 15:54                           ` Cyril Hrubis
2016-02-18  9:05                             ` Jan Stancek
2016-02-18 11:07                               ` Cyril Hrubis
2016-02-18 11:26                                 ` Jan Stancek
2016-02-18 11:53                                   ` Cyril Hrubis
2016-03-02 14:44                                   ` Cyril Hrubis
2016-03-03 13:13                                     ` Jan Stancek
2016-03-03 14:00                                       ` Cyril Hrubis
2016-03-10 16:57                                         ` Cyril Hrubis
2016-03-11 13:57                                           ` Jan Stancek
2016-03-14 12:51                                             ` Cyril Hrubis
2016-03-14 16:00                                               ` Cyril Hrubis
2016-03-15  8:58                                                 ` Jan Stancek
2016-03-15  9:22                                                   ` Cyril Hrubis
2016-03-17 16:06                                                     ` Cyril Hrubis
2016-03-18  9:44                                                       ` Jan Stancek
2016-03-31 10:01                                                         ` Cyril Hrubis
2016-04-01 14:45                                                           ` Jan Stancek
2016-04-04 12:04                                                             ` Cyril Hrubis
2016-04-04 14:12                                                               ` Jan Stancek
2016-04-05 14:16                                                                 ` Cyril Hrubis
2016-04-05 15:06                                                                   ` Jan Stancek
2016-04-06 10:37                                                                     ` Cyril Hrubis
2016-03-14 16:40                                             ` Cyril Hrubis
2016-02-18  9:14                             ` Alexey Kodanev
2016-02-18 10:40                               ` 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=116630920.20260383.1455280426104.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.