From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28875 invoked from network); 27 Jun 2022 09:24:08 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2022 09:24:08 -0000 Received: (qmail 25972 invoked by uid 550); 27 Jun 2022 09:24:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 25950 invoked from network); 27 Jun 2022 09:24:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656321833; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8bciCbWAx+cVhBti7yPxFeVIrGK9eyerI+p5WJ7ollo=; b=CeE/Ja6ANV5zPiCoMtu6csdsgJ9tT2CdqgdpycCJ9g+urbgrutnqqg266Ihcuv8GkCMP5f 4ofehUSLft7zxmdWQifohFJvwGezKNX6Zjdc0BzKzcZrqsvCCtpYsQkdreoMpIwE5WCIB2 frcoNLgGPx9ChzJif8D3mb8stttHMLc= X-MC-Unique: mszwlVepPwC7KRFakCAyDQ-1 From: Florian Weimer To: Nick Peng Cc: musl@lists.openwall.com References: <20220625125110.GV1320090@port70.net> <87k092eem6.fsf@oldenburg.str.redhat.com> <20220627083737.GW1320090@port70.net> Date: Mon, 27 Jun 2022 11:23:48 +0200 In-Reply-To: <20220627083737.GW1320090@port70.net> (Szabolcs Nagy's message of "Mon, 27 Jun 2022 10:37:37 +0200") Message-ID: <871qvae9y3.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [musl] BUG: Calling readdir/dirfd after vfork will cause deadlock. * Szabolcs Nagy: > * Florian Weimer [2022-06-27 09:42:57 +0200]: >> * Szabolcs Nagy: >> >> > * Nick Peng [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