Re: [BUG, TEST PATCH] stallout race between SIGCONT and SIGSTOP

[Joe Korty <joe.korty@ccur.com>]

On Wed, Sep 24, 2008 at 11:05:41AM -0400, Oleg Nesterov wrote:
> Joe says:
>> So it looks like the test is in error, not the kernel.
> 
> and I am happy to agree.
> I think sigaction/10-1.c should be fixed, please see the patch below.

A year or two ago I sent to Intel some OpenPosixTestSuite fixes, and they
were accepted.  Send it in (to the people listed in the comments at the
front of the .c file), hopefully they are still at Intel.


> Now, since SIGCHLD is a non-rt signal, the second SIGCHLD is lost,
> and wait_until_we_receive_CLD_STOPPED() hangs.
> 
> I did the test patch to be sure:
> 
>         --- 26-rc2/kernel/signal.c~     2008-09-20 20:37:52.000000000 +0400
>         +++ 26-rc2/kernel/signal.c      2008-09-24 18:43:34.000000000 +0400
>         @@ -808,7 +808,7 @@ static int send_signal(int sig, struct s
>                  * exactly one non-rt signal, so that we can get more
>                  * detailed information about the cause of the signal.
>                  */
>         -       if (legacy_queue(pending, sig))
>         +       if (sig != SIGCHLD && legacy_queue(pending, sig))
>                         return 0;
>                 /*
>                  * fast-pathed signals for kernel-internal things like SIGSTOP
> 
> and now your test-case doesn't hang.

Very interesting!  I am not sure this is Posix conformant, as Posix
seems to say that posting a SIGSTOP or SIGCHLD clears out all pending
SIGSTOPs or SIGCHLDs, so queueing the SIGCHLD might violate the standard.
Still it might be workable as it would be hard to see, from userspace, any
behavioral difference between queueing (possibly illegal) and synchronous
operation (which seems legal), both of which service all SIGCONTs and
SIGSTOPs without loss.

Joe