Bug 218757 - running 32-bit executables on x86_64 causes "vm_committed_space" value to increase inappropriately
running 32-bit executables on x86_64 causes "vm_committed_space" value to inc...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
high Severity medium
: ---
: ---
Assigned To: Red Hat Kernel Manager
Martin Jenner
: 229587 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-12-07 06:30 EST by Alan Cox
Modified: 2010-10-22 03:19 EDT (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2007-0791
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-15 11:16:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Cox 2006-12-07 06:30:24 EST
Description of problem:
Centos user found problems with vm accounting and noted it appeared to be fixed
upstream but not in Centos (and it seems not in RHEL either)

GIT commit:
Comment 1 Burt Holzman 2006-12-26 12:18:25 EST
We have seen this VM accounting bug on kernel 2.6.9-42.0.2.ELsmp for x86_64 (but
it does not seem to be fixed in the latest revision either).  In particular,
vm.overcommit was set to 2, and the machines (which run a lot of short i386
binaries at high frequencies) refused to fork any more processes -- malloc() was
failing.  After killing all user processes, Committed_AS was still well over 8
GB, clearly an accounting leak.

Please make this a relatively high priority, as overcommit features on x86_64 is
essentially broken without it (we have set it to 0 for now).
Comment 2 Alan Cox 2007-01-26 05:46:08 EST
Also reported as affecting RHEL3
Comment 10 Ernie Petrides 2007-01-30 18:55:23 EST
Note that this problem (i.e., negative "vm_committed_space" value) is only
cosmetic (bogus /proc/meminfo "Committed_AS" value) when the system is booted
with the default setting for /proc/sys/vm/overcommit_memory.  It is only when
the "overcommit_memory" sysctl value has been set to 2 that the kernel will
alter its behavior based on the "vm_committed_space" value.

If a customer is experiencing ENOMEM errors in user-space programs on a system
with "overcommit_memory" set to 2, a work-around would be to use the default
setting instead.
Comment 11 Ernie Petrides 2007-01-30 20:11:25 EST
In the case of RHEL4 (unlike RHEL3), running a 32-bit executable on x86_64
results in incrementing the "Committed_AS" value by the initial stack size.

This is because a call to security_vm_enough_memory() was made in the version
of setup_arg_pages() in  arch/x86_64/ia32/ia32_binfmt.c, but VM_ACCOUNT is not
set in __VM_STACK_FLAGS, and thus unmap_vmas() doesn't count the pages in its
*nr_accounted arg, which leads to exit_mmap() not counting the pages in its
call to vm_unacct_memory().

Since this problem doesn't occur on x86, I'm changing the arch to x86_64 (but
it might occur on other 64-bit arches, too ... not yet verified).
Comment 12 Alan Cox 2007-01-31 08:07:44 EST
That isn't a workaround. The only case you set overcommit_memory to 2 is because
you can't tolerate out of memory kills. So turning it off isn't an answer. 
Doesn't look hard to fix fortunately, although the changes upstream are more
extensive than neccessary and fix stuff like mips that we don't care about.
Comment 13 Alan Cox 2007-01-31 08:25:36 EST
Digging more if we want a quick hack solution (eg someone wants a hotfix) then
we can just knock the enough memory check out of setup_arg_pages(). This will
make the checks a little out but we have a fair bit of slack in the default 50%
memory + swap assumption so only a deliberately hostile environment would
mistrigger out of memory situations.  Not a good fix for the final release but
probably adequate if someone needs a hotfix.
Comment 14 Ernie Petrides 2007-01-31 20:08:03 EST
Note that RHEL3 bug 224600 is a different problem.

I'll develop and test a fix for the RHEL4 bug tomorrow (probably
just adding VM_ACCOUNT to __VM_STACK_FLAGS on x86_64), which I'd
guess will be a minimal enough risk for a RHEL4 Update (and even
for a potential U5 respin, if it's deemed necessary).
Comment 15 Ernie Petrides 2007-02-01 19:14:52 EST
I'm changing the subject line to reflect what the real problem is in RHEL4,
which exists solely on the x86_64 arch (in 32-bit exec support).

Note that the upstream changes indicated in the "GIT commit" link in the
initial comment of this bug report do not address the RHEL4 problem, which
is causing the kernel's "vm_committed_space" global variable to increase
inappropriately (eventually leading to user-space memory allocation failures
if a system were booted in the non-default overcommit_memory mode 2).

Note that this problem does not exist in RHEL3.  (But RHEL3 has a different
problem in maintaining the "vm_committed_space" global variable.)
Comment 16 Ernie Petrides 2007-02-01 20:16:52 EST
Patch posted for internal review on 1-Feb-2007.
Comment 17 RHEL Product and Program Management 2007-02-02 09:24:07 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 19 Ernie Petrides 2007-02-28 17:03:58 EST
*** Bug 229587 has been marked as a duplicate of this bug. ***
Comment 20 RHEL Product and Program Management 2007-04-18 18:42:48 EDT
This request was evaluated by Red Hat Kernel Team for inclusion in a Red
Hat Enterprise Linux maintenance release, and has moved to bugzilla 
status POST.
Comment 21 Jason Baron 2007-05-11 14:31:02 EDT
committed in stream U6 build 55.2. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 29 errata-xmlrpc 2007-11-15 11:16:51 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.