Re: [PATCH][RFC] Allow explicit shrinking of arena heaps using anenvironment variable

[Rich Felker <dalias at aerifal dot cx>]

On Fri, Jul 20, 2012 at 02:47:53PM -0700, Roland McGrath wrote:
> > Using madvise (MADV_DONTNEED) then mprotect should be equivalent to
> > mmap, but it's unclear to me which will be faster.
> 
> They're not equivalent from a security paranoia point of view.
> madvise just gives the kernel license to drop the pages.  It doesn't
> require that it do so.  A kernel could very well do nothing
> immediately at all in response to the madvise call, and it would be
> right to do nothing if that's the quickest thing and there is no
> memory pressure at all.  (If memory pressure arises later on, then
> it may well choose those pages as the first to reclaim.)  If the
> kernel didn't in fact drop the pages, then mprotect doesn't affect
> whether the old data is still there in those pages.  A later
> mprotect could very well make the old data accessible again.

The existing Linux semantics are (roughly) for madvise(MADV_DONTNEED)
to immediatley discard the pages and replace them with virgin COW
references to whatever they originally referenced - in the case of
anonymous pages, copies of the zero page. I think it would be a pretty
bold move for the kernel developers to change this, especially since
programs may be (whether rightly or wrongly) relying on it for
security purposes. I also think it would be more work to implement the
semantics you're talking about; the bigger threat is that they might
just make MADV_DONTNEED a no-op if it became a burden to keep the
functionality around.

With that said, it's probably worth benchmarking whether there's a
significant performance difference between madvise+mprotect and mmap.
In a best case, the latter could actually be faster since there's only
one round trip to kernelspace instead of two, and if simply calling
mmap performs better, it would make sense to just always use mmap even
if there's no security risk with madvise+mprotect.

Rich