[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170611133851.GY1627@brightrain.aerifal.cx>
Date: Sun, 11 Jun 2017 09:38:51 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: a workaround when mremap() is not functional?
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@...ey.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
View attachment "mremap_may_not_work.diff" of type "text/plain" (684 bytes)
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.
