From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8274 invoked from network); 14 Aug 2020 22:15:01 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 14 Aug 2020 22:15:01 -0000 Received: (qmail 24210 invoked by uid 550); 14 Aug 2020 22:14:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24182 invoked from network); 14 Aug 2020 22:14:58 -0000 Date: Fri, 14 Aug 2020 18:14:46 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200814221446.GQ3265@brightrain.aerifal.cx> References: <20200814214136.GP3265@brightrain.aerifal.cx> <871rk8opie.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871rk8opie.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Restrictions on child context after multithreaded fork On Sat, Aug 15, 2020 at 12:02:01AM +0200, Florian Weimer wrote: > * Rich Felker: > > > In case we do want to follow a direction of trying to provide some > > degree of relaxation of restrictions on the child (taking the liberty > > of POSIX-future drop of fork's AS-safety requirement), I did a quick > > survey of libc-internal locks, and found: > > pthread_once is another source of problems, although there seem to be > few users in musl. Indeed, there are a few internal uses of pthread_once and public locking functions that I missed (I only checked internal LOCK()). So at least the following are also involved: - timer_create (will go away once I rip out signal-based SIGEV_THREAD and implement SIGEV_THREAD timers entirely in userspace) - aio (I'm not sure it's worth considering since it's probably another area that's impossible to make safe to use in forked context) - newlocale - pthread_mutexattr_setprotocol - pthread_mutexattr_setrobust For the most part, I believe the "once" operations performed in these are essentially idempotent, so it would probably suffice to have them just provide "reset" code that zeros the once object in the child if needed. Rich