From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4447 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing sbrk and brk Date: Thu, 2 Jan 2014 17:03:02 -0500 Message-ID: <20140102220302.GR24286@brightrain.aerifal.cx> References: <20131221234041.GA13204@brightrain.aerifal.cx> <20131222184855.GS1685@port70.net> <20131223044609.GZ24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388700234 25681 80.91.229.3 (2 Jan 2014 22:03:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jan 2014 22:03:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4451-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 02 23:04:01 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VyqMy-0006Nz-I5 for gllmg-musl@plane.gmane.org; Thu, 02 Jan 2014 23:04:00 +0100 Original-Received: (qmail 5370 invoked by uid 550); 2 Jan 2014 22:03:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5277 invoked from network); 2 Jan 2014 22:03:15 -0000 Content-Disposition: inline In-Reply-To: <20131223044609.GZ24286@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4447 Archived-At: 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