[PATCH 2/3] nptl: Do not always assume set_robust_list availability (BZ 33225)

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 30/07/25 03:41, Andreas Schwab wrote:
>> On Jul 29 2025, Florian Weimer wrote:
>> 
>>> I'm not sure this is the right direction.  Is qemu-user compatibility
>>> that important to users?
>> 
>> For example, openSUSE Tumbleweed for RISC-V is built completely with
>> qemu user-space emulation (we don't have this issue right now since our
>> glibc is built with the default minimum kernel that still enables the
>> runtime check).
>> 
>> FWIW, the other big problem for qemu user-space emulation is posix_spawn
>> because the emulation does not implement a true CLONE_VFORK (it emulates
>> it with fork).  This breaks situations where there are errors in the
>> child process until and including execve; that failure cannot be
>> communicated back to the parent process.
>> 
>
> Is there any technical reason to not proper implement CLONE_VFORK? It
> should be feasible to add a workaround to user fork/execve plus pipe
> communication (like old implementation) if clone (CLONE_VFORK) fails,
> but this really adds some extra maintainability. 

Straightforward CLONE_VFORK shares the emulator state across processes,
which is undesirable.  Valgrind has the same problem.

Emulating CLONE_FORK with userfaultfd should be possible, but there may
be higher priorities given that vfork-as-fork almost works.

Thanks,
Florian