Re: posix_spawn: parent can get stuck in uninterruptible sleep if child receives SIGTSTP early enough

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 22/09/22 09:18, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 13/09/22 07:04, Florian Weimer wrote:
>>> * Adhemerval Zanella Netto:
>>>
>>>> On 22/08/22 15:21, Florian Weimer wrote:
>>>>> * Adhemerval Zanella Netto via Libc-help:
>>>>>
>>>>>> Right, my mistake.  I understood the issue better now, although I am
>>>>>> still puzzled why SIGTSTP is only being triggered on sigprocmask (sing
>>>>>> default action is still to stop PROCESS).
>>>>>
>>>>> I think it's a maskable stop, not an unmaskable one, like SIGSTOP.
>>>>
>>>> Yeah, we do block the signal on parent (internal_signal_block_all). 
>>>>
>>>>>
>>>>> This looks a vfork-specific bug that can't happen with fork.  I don't
>>>>> see how to fix it in a generic fashion because we can't unblock SIGTSTP
>>>>> and launch the new process in an atomic fashion.
>>>>
>>>> We might ask for a new clone3 field to define the default signal mask on 
>>>> process start (and thus omit the final sigprocmask before execve).
>>>
>>> It might already possible to fix this using io_uring.  Unfortunately, I
>>> didn't attend the LPC presentation.
>>
>> Is there anything that prevents to avoid using CLONE_VFORK? The code already
>> uses a allocated stack and do synchronizes with waitpid.
> 
> Assuming there is a way to create a thread which gets replaced by execve
> only (instead the whole process), this won't work because we have to
> block all signals for the new thread (it must not be visible to
> application code, and signal handlers must not run on it), and we can't
> unblock those signals prior to execve.  With vfork, we can unblock them
> after changing the signal handler disposition to SIG_DFL (preventing the
> handler execution), but per-thread signal handlers have been removed
> from Linux.  So even if we somehow could prevent the termination signal
> from beign sent to the whole process (and not just the fake thread), we
> still have a gap.

But we already block all internal signals with internal_signal_block_all
prior clone call and it does not use CLONE_SIGHAND on the clone call. 
Also, independently of CLONE_SIGHAND, the calling process and child still 
have distinct signal masks.  Recall for posix_spawn we do not use
CLONE_THREAD, so per-thread signal handlers does not apply here.

Doing some tests, the main problem is in fact how to synchronize 
the deallocation of the stack, since without CLONE_VFORK there is no way
to advertise on a success call when execve has been called.

But I agree that even without CLONE_VFORK we still have a small window,
between the sigprocmask and execve, that the signal might act upon the
child.