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 14219 invoked from network); 16 Aug 2020 16:56:18 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Aug 2020 16:56:18 -0000 Received: (qmail 26427 invoked by uid 550); 16 Aug 2020 16:56:12 -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 26404 invoked from network); 16 Aug 2020 16:56:11 -0000 Date: Sun, 16 Aug 2020 12:55:56 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200816165556.GY3265@brightrain.aerifal.cx> References: <20200814214136.GP3265@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Restrictions on child context after multithreaded fork On Sun, Aug 16, 2020 at 09:05:28AM +0200, Pirmin Walthert wrote: > Dear Rich, > >I've seen suspicions that the switch to mallocng exposed this, but I'm > >pretty sure it was: > > > >https://git.musl-libc.org/cgit/musl/commit/?id=e01b5939b38aea5ecbe41670643199825874b26c > > I needed to patch asterisk because of similar issues (you gave me > some hints on this mailing list after I'd described the issue): > > https://issues.asterisk.org/jira/browse/ASTERISK-28776 > > However this happened with a combination of musl 1.2.0, which did > not have the mentioned commit applied, and mallocng (LD_PRELOAD > method). Asterisk with 1.2.0 and old malloc was running just fine. Yes, if you were using mallocng out-of-tree it doesn't integrate with musl's internal locking, and would always perform locks regardless of whether multithreaded. This is even stronger than the above-cited change. Rich