Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 27 Jun 2022 19:33:14 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Florian Weimer <fweimer@...hat.com>
Cc: Nick Peng <pymumu@...il.com>, musl@...ts.openwall.com
Subject: Re: BUG: Calling readdir/dirfd after vfork will cause
 deadlock.

* Florian Weimer <fweimer@...hat.com> [2022-06-27 11:23:48 +0200]:
> * 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).

ah i thought vfork stops the entire parent process (based on linux man).

ok then i think musl should work too in practice..
however on some targets musl just uses a fork syscall instead of vfork.
i think that's the reason why this fails on aarch64 and mips.

so i think if musl adds src/process/ARCH/vfork.s then it would work.

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.