From: Florian Weimer <firstname.lastname@example.org>
To: Nick Peng <email@example.com>
Subject: Re: [musl] BUG: Calling readdir/dirfd after vfork will cause deadlock.
Date: Mon, 27 Jun 2022 11:23:48 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <20220627083737.GW1320090@port70.net> (Szabolcs Nagy's message of "Mon, 27 Jun 2022 10:37:37 +0200")
* Szabolcs Nagy:
> * Florian Weimer <email@example.com> [2022-06-27 09:42:57 +0200]:
>> * Szabolcs Nagy:
>> > * Nick Peng <firstname.lastname@example.org> [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
next prev parent reply other threads:[~2022-06-27 9:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-25 3:40 Nick Peng
2022-06-25 12:51 ` Szabolcs Nagy
2022-06-27 4:05 ` Nick Peng
2022-06-27 10:38 ` Laurent Bercot
2022-06-27 14:21 ` Rich Felker
2022-06-27 14:29 ` Markus Wichmann
2022-06-27 7:42 ` Florian Weimer
2022-06-27 8:37 ` Szabolcs Nagy
2022-06-27 9:23 ` Florian Weimer [this message]
2022-06-27 17:33 ` Szabolcs Nagy
2022-06-25 12:56 ` Alex Xu (Hello71)
2022-06-27 7:44 ` Florian Weimer
2022-06-27 12:28 ` Alex Xu (Hello71)
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).