[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Jan 2014 17:03:02 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Removing sbrk and brk
On Sun, Dec 22, 2013 at 11:46:09PM -0500, Rich Felker wrote:
> > so the options in increasing effort are
> >
> > 1) leave it as is
> > 2) completely remove sbrk/brk
> > 3) always fail (except for sbrk(0))
> > 4) emulate with mmap+mprotect
> > 5) malloc without brk
> >
> > i like 1) or 3) for 1.0 and 5) for post-1.0
>
> I agree mostly. Option 5 would be ideal, but it depends on determining
> whether there would be detrimental affects on performance. Even if
> there are, however, it may be acceptable since I eventually want to
> drop the madvise-based approach to returning memory to the kernel,
> which doesn't relinquish any commit charge, and replace it with
> PROT_NONE...
>
> For now though it seems we're trying to decide between options 1 and
> 3. If we go for option 1, we should fix the integer overflow/wrapping
> issue in sbrk you reported on irc..
OK, I'm modifying sbrk so sbrk(0) returns the current brk and
sbrk(nonzero) returns (void*)-1 with errno set to ENOMEM (option 3
above). This should help us catch any programs attempting to use sbrk
for memory management and get them fixed rather than dealing with
hideous memory-corruption errors that are hard to track down, and
we'll have some time to track them down between now and 1.0.
sbrk may be re-added sometime after 1.0 if malloc is changed to no
longer use the brk (option 5 above).
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.
