This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][RFC] Allow explicit shrinking of arena heaps using anenvironment variable
- From: Rich Felker <dalias at aerifal dot cx>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 1 Aug 2012 08:27:06 -0400
- Subject: Re: [PATCH][RFC] Allow explicit shrinking of arena heaps using anenvironment variable
- References: <20120725183634.E0C5F2C0B1@topped-with-meat.com><CAHGf_=qCMy6K1MD4miN65GkMSumYTtH23xoFrfmCuh=WjybAVA@mail.gmail.com><20120730230006.355f9b67@spoyarek><5016D012.5000101@gmail.com><20120730191758.GX544@brightrain.aerifal.cx><CAHGf_=rRm4B4YCZKgos5hWN_QTYV76fAxcegO7D3x=4_A88Rvw@mail.gmail.com><20120731132705.GZ544@brightrain.aerifal.cx><5017DECB.9030405@redhat.com><20120801041303.GA544@brightrain.aerifal.cx><5018D9B4.9020707@redhat.com>
On Wed, Aug 01, 2012 at 09:24:36AM +0200, Florian Weimer wrote:
> >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
Why? PROT_NONE is not special here. All that matters is that
PROT_WRITE is not included. The same is true of read-only clean
anonymous maps (all zero) or read-only maps of files. The best example
is the program's .text/.rodata/etc. PT_LOAD segment that's read-only.
Except in the case of textrels (where it was temporarily made writable
and part or all of it was dirtied), this map does not contribute to
commit charge; if it did, the concept of shared program text would be
nearly meaningless.
> 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.
MAP_NORESERVE is a historical relic that violates the principle of
no-overcommit. It cannot be allowed to work, because it does not only
affect the calling process. If memory is overcommitted, any other
process could later fail when the kernel is unable to satisfy the
memory committed to that process; this would be a serious
vulnerability.
MAP_NORESERVE is supposedly still honored if the old imprecise
pseudo-no-overcommit mode (vm.overcommit_memory=0) is used, but I have
not tested this.
Anyway, the failure of a hackish option to override commit accounting
has no relationship to whether correct, accurate commit accounting
works. PROT_NONE (or any non-writable, non-dirty map) counts as the
latter.
> Perhaps we should add a test case for the intended mprotect behavior?
Just make a 2gb PROT_NONE map and fork a few thousand times... :-)
Rich