From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] mtest01 parent/child process synchronization issue
Date: Thu, 26 Nov 2015 09:38:48 -0500 (EST) [thread overview]
Message-ID: <7533547.18002409.1448548727996.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <565591C8.7060308@redhat.com>
----- Original Message -----
> From: "Jiri Vohanka" <jvohanka@redhat.com>
> To: "Jan Stancek" <jstancek@redhat.com>, ltp@lists.linux.it
> Sent: Wednesday, 25 November, 2015 11:47:36 AM
> Subject: Re: [LTP] mtest01 parent/child process synchronization issue
>
> Hi,
Hi,
pushed with some changes, see comments below.
>
> >> diff --git a/testcases/kernel/mem/mtest01/mtest01.c
> >> b/testcases/kernel/mem/mtest01/mtest01.c
> >> index 8c9e81c..06f41d5 100644
> >> --- a/testcases/kernel/mem/mtest01/mtest01.c
> >> +++ b/testcases/kernel/mem/mtest01/mtest01.c
>
> >> @@ -51,9 +51,12 @@
> >> char *TCID = "mtest01";
> >> int TST_TOTAL = 1;
> >> int pid_count = 0;
> >> +int oom_count = 0;
> >
> > both of these should be static
>
> You are right, I also added volatile just to be sure.
I changed it to:
static sig_atomic_t sigchld_count;
>
> >> @@ -284,7 +288,9 @@ int main(int argc, char *argv[])
> >> kill(pid_list[i], SIGKILL);
> >> i++;
> >> }
> >> - if (dowrite)
> >> + if (oom_count)
> >> + tst_resm(TFAIL, "the child process was killed");
> >
> > I wouldn't combine two "if"s into one if else block, the information how
> > much was allocated could be useful even when we hit OOM.
>
> The original_maxbytes tells us how much we want to allocate, not how much was
> already allocated. You have to watch TINFO messages emitted by
> child processes to see what was actually allocated. I think that printing
> ""%llu kbytes allocated" would be misleading since that is true only
> if the test passes. I kept the if statement at its current place, but I made
> the fail message more verbose.
You're right, printing orig_maxbytes is useless.
>
> > But mainly, problem here is that ~6 lines above child processes get killed,
> > so you are racing with SIGCHLD here. I'd suggest to move this TFAIL before
> > kill() loop.
>
> I moved the part that kills the child processes after PASS/FAIL evaluation to
> avoid possible race condition.
> (Another option would be to uninstall the SIGCHLD signal handler before
> killing the processes.)
>
> >> + else if (dowrite)
> >> tst_resm(TPASS, "%llu kbytes allocated and used.",
> >> original_maxbytes / 1024);
> >> else
>
> I am new to the list and I am not sure what the rules for posting patches
> are. Should I use 'git send-email', sign the patch or something?
Yes, also good start is to check out "style-guide.txt" and
"test-writing-guidelines.txt" in doc directory.
Regards,
Jan
>
> Regards,
> Jiri
>
next prev parent reply other threads:[~2015-11-26 14:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 16:51 [LTP] mtest01 parent/child process synchronization issue Jiri Vohanka
2015-11-23 10:10 ` Jan Stancek
2015-11-25 10:47 ` Jiri Vohanka
2015-11-26 14:38 ` Jan Stancek [this message]
2015-11-26 14:50 ` 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=7533547.18002409.1448548727996.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox