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

[Florian Weimer <fweimer at redhat dot com>]

On 08/01/2012 06:13 AM, Rich Felker wrote:
> On Tue, Jul 31, 2012 at 03:34:03PM +0200, Florian Weimer wrote:
> > On 07/31/2012 03:27 PM, Rich Felker wrote:
> >
> > > I think this is about the third or forth time I've explained it now.
> > > PROT_NONE is needed to actually free the memory for other processes to
> > > use. MADV_DONTNEED frees the physical memory (eliminates dirty pages
> > > and thus prevents costly swapping of worthless data), but it does not
> > > free the commit charge because the pages are still potentially
> > > writable and thus not permanently backed by the zero page even though
> > > they initially just reference it.
> >
> > Good catch.  Do you know if this is part of the kernel ABI these
> > days? Last time I checked, it was not documented behavior, so I
> > feared that it was an accident of implementation.
>
> Which part are you talking about? The subtracting from commit charge?

Yes.

> Assuming your definition of commit charge for a process is the minimum
> amount of memory that must be reserved for it to make overcommit
> impossible (with no further assumptions on the process's behavior),
> omitting non-writable cleanly-backed mappings from the commit charge
> accounting is just part of the definition of commit charge.

I find it surprising that PROT_NONE does not count against the commit 
limit (at least for initial allocations in 2.6.32-era kernels, I have 
not checked if applying it retroactively using mprotect, or on newer 
kernels).  As you explain, it is sound to do this, but the the mmap(2) 
manual page suggests that MAP_NORESERVE has this effect as well, except 
that in reality, such a mapping does count against the limit.

Perhaps we should add a test case for the intended mprotect behavior?

--
Florian Weimer / Red Hat Product Security Team