[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200524031349.GN1079@brightrain.aerifal.cx>
Date: Sat, 23 May 2020 23:13:49 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: 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
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.
