Re: [LTP] [PATCH] Fix rt_sigtimedwait ordering test

[Will D. <wil...@ar...>]

Hi Garrett,

> > I've not heard anything further on this, but it does fix a real issue
> > on the platform I'm using. Do you need anything more from me for this
> > to be considered for committing?
> 
>     Kind of odd that only doing it there would fix the entire testcase
> as that's not the only pattern of
> 
> create_sig_proc(...)
> 
>     that isn't handled with a wait/waitpid.

It's not that strange because, in this testcase at least, we call
sigwaitinfo either with a timeout or a sigset_t in the parent. In
the latter case this will block until the signal is delivered so
the race between child and parent isn't a problem.

>     It just seems like there are tons of bugs lurking under the scenes
> with this create_sig_proc deal because it doesn't wait, and if the
> parent doesn't wait, then you're just creating a ton of races
> potentially if not handled properly.

The issue is when you have multiple children and the test relies
on a specific ordering of signal delivery (as is the case for RT
signals).

>     FWIW some more synchronization may need to be added in
> create_sig_proc (like blocking I/O with a pipe for instance, mq_*,
> sem_*? mq_* and sem_* are kind of undesirable though because those
> APIs are buggy on different architectures / versions of Linux, and
> pipes are generally simple enough to express synchronization), in
> order to ensure that things are deterministically ordered and the
> results of the test are sane.

I'm not sure this is necessary because it restricts the concurrency
for testcases where the race shouldn't matter.

Will