[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170611142847.GQ30784@example.net>
Date: Sun, 11 Jun 2017 16:28:48 +0200
From: u-uy74@...ey.se
To: musl@...ts.openwall.com
Subject: Re: a workaround when mremap() is not functional?
On Sun, Jun 11, 2017 at 09:38:51AM -0400, Rich Felker wrote:
> > 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.
FreeBSD's linux_mremap() seems to be able to shrink the mapping
but it is not possible to know for all implementations.
> 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;
This looks working on FreeBSD, as expected!
Thanks a lot for this very timely tweak, what a relief.
Regards,
Rune
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.
