[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871qvae9y3.fsf@oldenburg.str.redhat.com>
Date: Mon, 27 Jun 2022 11:23:48 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Nick Peng <pymumu@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: BUG: Calling readdir/dirfd after vfork will cause deadlock.
* Szabolcs Nagy:
> * Florian Weimer <fweimer@...hat.com> [2022-06-27 09:42:57 +0200]:
>> * Szabolcs Nagy:
>>
>> > * Nick Peng <pymumu@...il.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
