mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: a workaround when mremap() is not functional?
Date: Sun, 11 Jun 2017 09:38:51 -0400	[thread overview]
Message-ID: <20170611133851.GY1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <20170611131713.GX1627@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Sun, Jun 11, 2017 at 09:17:13AM -0400, Rich Felker wrote:
> On Sun, Jun 11, 2017 at 11:51:14AM +0200, u-uy74@aetey.se wrote:
> > Is there any variation to the musl malloc which would make realloc()
> > work when the Linux ABI implementation lacks a usable mremap()?
> > 
> > Otherwse realloc() under Linux ABI in FreeBSD fails due to mremap()
> > being mostly a stub and returning -1/ENOMEM for any growth.
> > 
> > LinuxABI under FreeBSD apparently behaves differently than the
> > Linux kernel, which can be seen as bugs when the purpose is "Linux
> > compatibility".
> > 
> > OTOH it would be nice to reduce the strength of the conformity
> > requirements by musl, to be able to accomodate the extra platform
> > (possibly could help on other platforms too).
> 
> This was already on my radar because mremap for enlarging anon
> mappings is also broken on nommu Linux. I think I just need to add a
> "if failed, goto the existing malloc-and-memcpy-and-free code"
> one-liner.

Does the attached work for you? It eliminates the old behavior of
keeping the old mapping on failure when shrinking since that can lead
to massive memory waste (e.g. malloc huge buffer in case you need it,
then shrink to tiny one) if mremap failure-to-shrink is something that
may be common and not just for the VMA-limit-exceeded case.

Rich

[-- Attachment #2: mremap_may_not_work.diff --]
[-- Type: text/plain, Size: 683 bytes --]

diff --git a/src/malloc/malloc.c b/src/malloc/malloc.c
index c38c46f..d5ee428 100644
--- a/src/malloc/malloc.c
+++ b/src/malloc/malloc.c
@@ -406,7 +406,7 @@ void *realloc(void *p, size_t n)
 		if (oldlen == newlen) return p;
 		base = __mremap(base, oldlen, newlen, MREMAP_MAYMOVE);
 		if (base == (void *)-1)
-			return newlen < oldlen ? p : 0;
+			goto copy_realloc;
 		self = (void *)(base + extra);
 		self->csize = newlen - extra;
 		return CHUNK_TO_MEM(self);
@@ -439,6 +439,7 @@ void *realloc(void *p, size_t n)
 		return CHUNK_TO_MEM(self);
 	}
 
+copy_realloc:
 	/* As a last resort, allocate a new chunk and copy to it. */
 	new = malloc(n-OVERHEAD);
 	if (!new) return 0;

  reply	other threads:[~2017-06-11 13:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-11  9:51 u-uy74
2017-06-11 13:17 ` Rich Felker
2017-06-11 13:38   ` Rich Felker [this message]
2017-06-11 14:28     ` u-uy74

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170611133851.GY1627@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).