Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87eeo6ikhi.fsf@mid.deneb.enyo.de>
Date: Sun, 16 Aug 2020 19:11:37 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Restrictions on child context after multithreaded fork

* Rich Felker:

> On Sun, Aug 16, 2020 at 11:10:37AM +0200, Florian Weimer wrote:
>> * Rich Felker:
>> 
>> > On some inspection, glibc does not actually attempt to make the child
>> > environment unrestricted. The only things it does around fork are:
>> 
>> I think pthread_once initializers that have partially executed are
>> also executed from the start in the child if initialization is
>> requested again.
>
> I don't follow how pthread_once is related. The vast majority of the
> things I found glibc doing no specific handling for are actual mutable
> state not just on-demand initialization.

If a fork happens during a pthread_once initialization, the subsystem
related to that becomes unavailable after fork.  The pthread_once_t
reinitialization logic intends to avoid that.  Like resetting locks
after fork in the new process, it is rather questionable.

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.