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 14733 invoked from network); 24 May 2020 03:14:04 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 May 2020 03:14:04 -0000 Received: (qmail 26566 invoked by uid 550); 24 May 2020 03:14:02 -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 26535 invoked from network); 24 May 2020 03:14:01 -0000 Date: Sat, 23 May 2020 23:13:49 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200524031349.GN1079@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] Closing out oldmalloc Before dropping in mallocng and saying goodbye to oldmalloc, I'd kinda like to leave its final state as something "non-broken" -- in particular, without the unbounded heap expansion bug. There's a patch from around a year ago that some affected users have tried, that should fix it fully, and that removes a lot of the sketchy/fragile code including the stuff broken by the lock-skipping bug: https://www.openwall.com/lists/musl/2019/04/12/4 I think I'd like to apply this. It probably wouldn't get much/any use and wouldn't appear as the malloc used in a release, but would be nice to have it somewhere where it's not forgotten. It could also be a candidate for backporting to the 1.1.x branch if that ends up happening. There's a smallish possibility I might continue to support oldmalloc as an option for at least a few releases in case any of the properties of mallocng end up being a problem for current users, since I don't want it to be holding back upgrade. It's bad enough that time64 has some distros holding back already. If so, having the fix in would be nice, even if it is something of a performance regression, so we're not giving users an option that's known-broken. If anyone has opinions on this stuff, now's the time to get out the paint and speak up. Rich