[Intel-gfx] [PATCH igt] core/sighelper: Interrupt everyone in the process group

[Daniel Vetter]

On Mon, Jan 11, 2016 at 08:54:59AM +0000, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote:
> > On Fri, Jan 08, 2016 at 08:44:29AM +0000, Chris Wilson wrote:
> > > Some stress tests create both the signal helper and a lot of competing
> > > processes. In these tests, the parent is just waiting upon the children,
> > > and the intention is not to keep waking up the waiting parent, but to
> > > keep interrupting the children (as we hope to trigger races in our
> > > kernel code). kill(-pid) sends the signal to all members of the process
> > > group, not just the target pid.
> > 
> > I don't really have any clue about unix pgroups, but the -pid disappeared
> > compared to the previous version.
> 
> -getppid().
> 
> I felt it was clearer to pass along the "negative pid = process group"
> after setting up the process group.

Oh, I was blind ... Yeah looks better, but please add a bigger comment
around that code explaining why we need a group and why we use SIG_CONT.
With that acked-by: me.

Cheers, Daniel

> > > We also switch from using SIGUSR1 to SIGCONT to paper over a race
> > > condition when forking children that saw the default signal action being
> > > run (and thus killing the child).
> > 
> > I thought I fixed that race by first installing the new signal handler,
> > then forking. Ok, rechecked and it's the SYS_getpid stuff, so another
> > race. Still I thought signal handlers would survive a fork?
> 
> So did irc. They didn't appear to as the children would sporadically
> die with SIGUSR1.

Could be that libc is doing something funny, iirc they have piles of fork
helpers to make fork more reliable (breaking locks and stuff like that),
but then in turn break the abstraction.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch