Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140329185619.GX26358@brightrain.aerifal.cx>
Date: Sat, 29 Mar 2014 14:56:19 -0400
From: Rich Felker <dalias@...ifal.cx>
To: u-igbb@...ey.se
Cc: musl@...ts.openwall.com
Subject: Re: malloc not behaving well when brk space is limited?

On Sat, Mar 29, 2014 at 06:02:29PM +0000, u-igbb@...ey.se wrote:
> > Unfortunately the approach I want to use with mmap seems to be what
> > glibc uses for its thread-local arenas, and it performs something like
> > 2 to 10 times worse than brk... So unless we can solve that, I don't
> > think it's a good option. It could be a fallback, but I still don't
> > want PIE binaries running that much slower just because the kernel is
> > doing something wacky and wrong.
> 
> It is a _lot_ better to run an order of magnitude slower than to fail
> totally, isn't it? If you have any code doing mmap-fallback, I would be
> willing to test it and hopefully use.
> 
> > We need a good solution for this problem but I don't have one yet.
> 
> This looks like a showstopper. The applications do not work properly
> as-is and replacing malloc or adding mmap support from scratch by myself
> is a threshold too high, given the time constraints. :(
> 
> In other words, a bad solution would be much better than no solution.
> 
> Otherwise my impression from musl until now is excellent. Thanks
> for your work on it.

Yes, I understand. I didn't mean that this can't or shouldn't be
fixed, just that the changes I had hoped to make to malloc in the
1.1.x series are not looking like the right direction for fixing this,
so we're back to the question of what to do.

If you need a fix (or at least a workaround) right away, let me know
and I'll see if I can think of anything.

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.