[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DLU5IDY7FCX4.OWYMCXDOF2R5@trevorgross.com>
Date: Fri, 02 Oct 2026 01:50:22 -0500
From: "Trevor Gross" <tg@...vorgross.com>
To: "Florian Weimer" <fweimer@...hat.com>, "Rich Felker" <dalias@...c.org>
Cc: "Trevor Gross" <tg@...vorgross.com>, "Alejandro Colomar"
<alx@...nel.org>, <linux-man@...r.kernel.org>, <libc-alpha@...rceware.org>,
<musl@...ts.openwall.com>
Subject: Re: [PATCH 2/2] man/man2/fork.2: Document glibc and musl
relaxed fork->exec AS requirements
On Fri Sep 25, 2026 at 2:54 PM CDT, Florian Weimer wrote:
> * Rich Felker:
>
>>> +On glibc and musl libc, this is relaxed;
>>> +it is safe to call non-async-signal-safe functions in the time between
>>> +.BR fork ()
>>> +and
>>> +.BR exec ()
>>> +\&.
>
>> While glibc has taken measures to make this mostly work, especially
>> malloc-after-fork, I don't think glibc has an intentional model for
>> ensuring that arbitrary libc functions work right in the child of a
>> multithreaded fork. Before accepting such a man page patch, we should
>> at least get an official position from glibc on whether they claim
>> this property or at least aim for it.
>
> Far from everything in glibc is fork-protected, so the statement is not
> true today as far as glibc is concerned. We try to maintain
> compatibility with existing application requirements, but the precise
> goals have not been written down.
Would the following be more accurate?
On glibc and musl libc, this is relaxed. With musl environments, it
is safe to call non-async-signal-safe functions in the time between
fork() and exec(). With glibc environments, some functions that are
not AS-safe may be called between fork() and exec() may be safe to
call; however, there is no exact list maintained.
Open to better wording as well, I'm not sure sure how best to express
the glibc case - if that's worth it at all.
Rich, is this reasonable to document for musl? It is a rather helpful
property even if not portable, but I'm not sure whether it is more of an
implementation detail for improved compatibility vs. something musl is
comfortable with users relying on.
- 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.
