[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <591a1789-bed4-48ff-958f-867f8688a8ac@gmail.com>
Date: Sat, 3 Oct 2026 22:48:17 +0200
From: Gabriel Ravier <gabravier@...il.com>
To: Trevor Gross <tg@...vorgross.com>, Florian Weimer <fweimer@...hat.com>,
Rich Felker <dalias@...c.org>
Cc: 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 10/2/26 8:50 AM, Trevor Gross wrote:
> 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.
At the very least, it shouldn't duplicate the "may be safe to call"
clause :p
>
> 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.
