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

[Florian Weimer <fweimer@redhat.com>]

* 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.

Thanks,
Florian