Date: Tue, 2 Jun 2020 17:16:39 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Closing out oldmalloc On Sat, May 23, 2020 at 11:13:49PM -0400, Rich Felker wrote: > 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. I have a reduced version of it with minor fixes that I very well may commit. The only intended functional change is that, unlike the above, it keeps the ability to split chunks that are in the desired bin but larger than needed to satisfy the allocation request. This of course makes more cases where the full split/merge lock must be taken. For what it's worth, in the limited tests I've done, before or after the changes it's barely faster and possibly slower than just using a single global lock. However I think theoretically what remains of the fine-grained locking still can help real multithreaded loads with sufficient fragmentation that the bins usually have free chunks in them. Rich View attachment "oldmalloc_fix.diff" of type "text/plain" (8687 bytes)
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.