All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: IGT development <igt-dev@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 3/9] lib: Don't leak children in igt_waitchildren_timeout
Date: Mon, 11 Feb 2019 23:01:16 +0000	[thread overview]
Message-ID: <154992607608.14378.13727024411543835857@skylake-alporthouse-com> (raw)
In-Reply-To: <20190211223825.GV23159@phenom.ffwll.local>

Quoting Daniel Vetter (2019-02-11 22:38:25)
> On Mon, Feb 11, 2019 at 09:03:12PM +0000, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-02-11 18:02:02)
> > > Instead of cleaning up the mess in igt_exit make sure we don't even
> > > let it out of the container. See also
> > > 
> > > commit 754876378d6c9b2775e8c07b4d16f9878c55949f
> > > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > > Date:   Fri Feb 26 22:11:10 2016 +0000
> > > 
> > >     igt/gem_sync: Enforce a timeout of 20s
> > > 
> > > which added this helper.
> > > 
> > > To make sure that everyone follows the rules, add an assert.
> > > 
> > > We're keeping the cleanup code as a failsafe, and because it speeds
> > > up the testcase I'm following up with.
> > > 
> > > v2: Chris pointed out that my original patch did nothing. Which I
> > > didn't catch because my testcase was also broken. Unfortunately this
> > > means we need to open code part of the waiting.
> > > 
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  lib/igt_core.c | 39 ++++++++++++++++++++++++++++++++++-----
> > >  1 file changed, 34 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > > index cbbe79f88070..3053697da58c 100644
> > > --- a/lib/igt_core.c
> > > +++ b/lib/igt_core.c
> > > @@ -1525,6 +1525,7 @@ void igt_exit(void)
> > >  
> > >         for (int c = 0; c < num_test_children; c++)
> > >                 kill(test_children[c], SIGKILL);
> > > +       assert(!num_test_children);
> > >  
> > >         if (!test_with_subtests) {
> > >                 struct timespec now;
> > > @@ -1832,20 +1833,48 @@ void igt_waitchildren(void)
> > >                 igt_fail(err);
> > >  }
> > >  
> > > +static bool igt_killchidren_timed_out;
> > > +
> > > +static void igt_alarm_killchildren(int signal)
> > > +{
> > > +       igt_info("Timed out waiting for children\n");
> > 
> > We used to print the caller supplied reason. Although that appears to
> > have never been used, so might as well drop it from the API.
> > 
> > > +
> > > +       igt_killchidren_timed_out = true;
> > > +
> > > +       for (int c = 0; c < num_test_children; c++)
> > > +               kill(test_children[c], SIGKILL);
> > 
> > Ok, kill() is signal-safe.
> > 
> > > +}
> > > +
> > >  /**
> > >   * igt_waitchildren_timeout:
> > >   * @seconds: timeout in seconds to wait
> > >   * @reason: debug string explaining what timedout
> > >   *
> > > - * Wait for all children forked with igt_fork, for a maximum of @seconds.
> > > - *
> > > - * Wraps igt_waitchildren() and igt_set_timeout()
> > > + * Wait for all children forked with igt_fork, for a maximum of @seconds. If the
> > > + * timeout expires, kills all children and cleans them up.
> > >   */
> > >  void igt_waitchildren_timeout(int seconds, const char *reason)
> > >  {
> > > -       igt_set_timeout(seconds, reason);
> > > -       igt_waitchildren();
> > > +       struct sigaction sa;
> > > +       int ret;
> > > +
> > > +       sa.sa_handler = igt_alarm_killchildren;
> > > +       sigemptyset(&sa.sa_mask);
> > > +       sa.sa_flags = 0;
> > > +
> > > +       igt_killchidren_timed_out = false;
> > > +
> > > +       sigaction(SIGALRM, &sa, NULL);
> > > +
> > > +       alarm(seconds);
> > > +
> > > +       ret = __igt_waitchildren();
> > > +       if (!igt_killchidren_timed_out && ret)
> > > +               igt_fail(ret);
> > >         igt_reset_timeout();
> > > +       __igt_waitchildren();
> > > +       if (igt_killchidren_timed_out)
> > > +               igt_fail(IGT_EXIT_FAILURE);
> > 
> > Double __igt_waitchildren()? My reading of __igt_waitchildren() is that
> > it will continue on after the alarm() wakes wait() up with SIGINT and
> > repeat the wait() until all children die. And now those children will
> > die, rather than the parent as before.
> 
> igt_waitchildren_timeout before this patch wouldn't work if it did that.

Before this patch, the alarm handler did igt_fail -> exit(1) in the
parent.

> The pid == wait(); if (pid == -1) continue; bails out to the next child in
> case of interrupts. Hence the wait; kill; wait sequence here. I discovered
> this through testcases :-)

Now alarm -> wait() returning -1 + errno=EINTR, right? Then the
sighandler does killall -9, so on the next wait it sees that all the
children are dead.

__igt_waitchildren() even sets num_test_children = 0 on return, so the
second __igt_waitchildren() must do nothing. Or I am very confused.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-02-11 23:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 18:02 [igt-dev] [PATCH i-g-t 1/9] lib/tests: Check that igt_assert forwards correctly through igt_fork Daniel Vetter
2019-02-11 18:02 ` [igt-dev] [PATCH i-g-t 2/9] lib/tests: make sure igt_skip in igt_fork is forbidden Daniel Vetter
2019-02-11 18:02 ` [igt-dev] [PATCH i-g-t 3/9] lib: Don't leak children in igt_waitchildren_timeout Daniel Vetter
2019-02-11 21:03   ` Chris Wilson
2019-02-11 22:38     ` Daniel Vetter
2019-02-11 23:01       ` Chris Wilson [this message]
2019-02-12  8:45         ` Daniel Vetter
2019-02-12 12:04   ` [igt-dev] [PATCH i-g-t] " Daniel Vetter
2019-02-12 12:09     ` Chris Wilson
2019-02-12 12:46       ` Daniel Vetter
2019-02-12 16:02     ` Daniel Vetter
2019-02-12 16:08       ` Chris Wilson
2019-02-13 10:20         ` Daniel Vetter
2019-02-11 18:02 ` [igt-dev] [PATCH i-g-t 4/9] tests/gem_exec_reuse: Don't leak the hang detector Daniel Vetter
2019-02-11 18:06   ` Chris Wilson
2019-02-11 18:02 ` [igt-dev] [PATCH i-g-t 5/9] tests/i915_missed_irq: Don't leave the hang detector hanging Daniel Vetter
2019-02-11 18:08   ` Chris Wilson
2019-02-11 18:02 ` [igt-dev] [PATCH i-g-t 6/9] lib/tests: make sure we catch igt_fork leaks Daniel Vetter
2019-02-12 16:00   ` [igt-dev] [PATCH i-g-t] " Daniel Vetter
2019-02-11 18:02 ` [igt-dev] [PATCH i-g-t 7/9] lib: Make sure we leak no child processes Daniel Vetter
2019-02-11 21:06   ` Chris Wilson
2019-02-11 22:43   ` [igt-dev] [PATCH i-g-t] " Daniel Vetter
2019-02-12 16:48     ` Chris Wilson
2019-02-11 18:02 ` [igt-dev] [PATCH i-g-t 8/9] lib: Drop igt_child_done Daniel Vetter
2019-02-11 18:02 ` [igt-dev] [PATCH i-g-t 9/9] lib: Drop IGT_EXIT_TIMEOUT Daniel Vetter
2019-02-11 18:27 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/9] lib/tests: Check that igt_assert forwards correctly through igt_fork Patchwork
2019-02-11 22:15 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2019-02-12 12:46 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/9] lib/tests: Check that igt_assert forwards correctly through igt_fork (rev2) Patchwork
2019-02-12 14:59 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2019-02-12 16:09 ` [igt-dev] ✗ Fi.CI.BAT: failure for series starting with [i-g-t,1/9] lib/tests: Check that igt_assert forwards correctly through igt_fork (rev4) Patchwork
2019-02-12 16:44 ` [igt-dev] [PATCH i-g-t 1/9] lib/tests: Check that igt_assert forwards correctly through igt_fork Chris Wilson
2019-02-13 10:00   ` Daniel Vetter
2019-02-12 17:51 ` [igt-dev] ✗ Fi.CI.BAT: failure for series starting with [i-g-t,1/9] lib/tests: Check that igt_assert forwards correctly through igt_fork (rev5) Patchwork

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=154992607608.14378.13727024411543835857@skylake-alporthouse-com \
    --to=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=igt-dev@lists.freedesktop.org \
    /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.