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.