Re: [musl] BUG: Calling readdir/dirfd after vfork will cause deadlock.

[Florian Weimer <fweimer@redhat.com>]

* Szabolcs Nagy:

> * Florian Weimer <fweimer@redhat.com> [2022-06-27 09:42:57 +0200]:
>> * Szabolcs Nagy:
>> 
>> > * Nick Peng <pymumu@gmail.com> [2022-06-25 11:40:17 +0800]:
>> >> Description:  After vfork, calling functions such as readdir/dirfd may
>> >> cause deadlock. GNU C is OK.
>> >
>> > why do you think "GNU C is OK"? is this from some real software?
>> 
>> glibc supports opendir/readdir/closedir after vfork as an extension.
>> The JVM depends on it.
>
> how does that work? i think glibc just calls vfork syscall (or
> clone(CLONE_VM|CLONE_VFORK)) from asm and opendir allocates.
> so i'd expect a deadlock where the parent waits for the child
> to exec while holding the malloc lock.

vfork stops the thread in the parent and uses its resources.  It is the
same userspace thread (with the same TCB), only the kernel TID is wrong.
glibc's malloc-internal locks do not rely on the TID, so there is no
incrased risk of deadlock.  The malloc locks are internal, so user code
cannot call vfork while they are locked.  If another thread has locked
them at the point of vfork, that thread will eventually unlock them,
unblocking the vfork'ed subprocess.  This relies on the shared address
space of vfork.

Without the shared address space, none of this would work, and for fork,
we have complicated code to manage glibc-internal locks (including the
malloc locks).

Thanks,
Florian