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 1907 invoked from network); 31 Oct 2020 03:31:36 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 31 Oct 2020 03:31:36 -0000 Received: (qmail 20040 invoked by uid 550); 31 Oct 2020 03:31:30 -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 20013 invoked from network); 31 Oct 2020 03:31:29 -0000 Date: Fri, 30 Oct 2020 23:31:17 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20201031033117.GH534@brightrain.aerifal.cx> References: <20201027211735.GV534@brightrain.aerifal.cx> <20201030185205.GA10849@arya.arvanta.net> <20201030185716.GE534@brightrain.aerifal.cx> <5298816.XTEcGr0bgB@nanabozho> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5298816.XTEcGr0bgB@nanabozho> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH v2] MT fork On Fri, Oct 30, 2020 at 03:31:54PM -0600, Ariadne Conill wrote: > Hello, > > On Friday, October 30, 2020 12:57:17 PM MDT Rich Felker wrote: > > There was a regression in musl too, I think. With > > 27b2fc9d6db956359727a66c262f1e69995660aa you should be able to > > re-enable parallel mark. If you get a chance to test, let us know if > > it works for you. > > I have pushed current musl git plus the MT fork patch to Alpine edge as Alpine > musl 1.2.2_pre0, and reenabling parallel mark has worked fine. > > It would be nice to have a musl 1.2.2 release that I can use for the source > tarball instead of a git snapshot, but this will do for now. Thanks for the feedback. I'll try to wrap up this release cycle pretty quickly now, since I know this has been a big stress for distros, but I want to make sure the MT-fork doesn't introduce other breakage. One thing I know is potentially problematic is interaction with malloc replacement -- locking of any of the subsystems locked at fork time necessarily takes place after application atfork handlers, so if the malloc replacement registers atfork handlers (as many do), it could deadlock. I'm exploring whether malloc use in these systems can be eliminated. A few are almost-surely better just using direct mmap anyway, but for some it's borderline. I'll have a better idea sometime in the next few days. Rich