[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <lhuqzihxg1d.fsf@oldenburg.str.redhat.com>
Date: Fri, 25 Sep 2026 21:54:54 +0200
From: Florian Weimer <fweimer@...hat.com>
To: 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
* 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.
Thanks,
Florian
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.
