[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DLN4IBB6FV7K.WN3EVWC5FG17@trevorgross.com>
Date: Wed, 23 Sep 2026 19:34:35 -0500
From: "Trevor Gross" <tg@...vorgross.com>
To: <musl@...ts.openwall.com>, <tg@...vorgross.com>
Cc: <linux-man@...r.kernel.org>, <libc-alpha@...rceware.org>
Subject: Re: async-signal-safety of chroot
On Tue Sep 22, 2026 at 8:34 PM CDT, Rich Felker wrote:
>
> Also, both glibc and musl relax the restriction on only calling
> AS-safe functions in the child after a multi-threaded parent forks. In
> glibc this is sort of a best-effort thing, but in musl we went through
> a detailed process of ensuring that everything is made consistent for
> the child. The only thing that might not be consistent is dynamic
> linker state, which might make it impossible to dlopen in the child,
> but this is treated as a reportable error condition not a crash or
> deadlock or anything.
>
> The changes to lift the restrictions on the child happened in commit
> 167390f05564e0a4d3fcb4329377fd7743267560
>
> Rich
A followup question: the usual wisdom has been that `fork` must always
be followed by an `exec`, and not doing so is somewhere between
error-prone and completely unsound. Based per the commit it sounds like
there are no more deadlocks, and without the POSIX AS-safe requirement,
the soundness question goes away. Does this mean that it is now
considered correct and reasonable code to `fork` without `exec` for the
purpose of e.g. invoking a function in a separate process? Similar to
what can be done with `clone`.
Of course that case may be better served by a way to re-`exec` the same
process for clean state without relying on the exact same hacks, but
that unfortunately doesn't exist.
- Trevor
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.
