Bug 139881 - Incorrect accounting with locked_vm (struct mm_struct)
Incorrect accounting with locked_vm (struct mm_struct)
Status: CLOSED DUPLICATE of bug 126411
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ernie Petrides
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-18 11:56 EST by Wendy Cheng
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-21 22:11:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test program (100.00 KB, text/plain)
2004-11-18 12:09 EST, Wendy Cheng
no flags Details
wor around patch (597 bytes, text/plain)
2004-11-18 12:34 EST, Wendy Cheng
no flags Details

  None (edit)
Description Wendy Cheng 2004-11-18 11:56:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1)
Gecko/20020830

Description of problem:
 
From IT#53358:

Hitachi reports their customers can't do shmctl(.. SHM_LOCK ..). The
call frequently returns "Cannot allocate memory" regardless of the
amount of free memory.

Thru the test programs, we find the culprit is caused by SHM ops are
allowed based on "uid" between different processes but the counter
used to track the usages (current->mm->mm->locked_vm) is per process
based.  The problem can be easily shown by:

1. Run the "shmget" test program to get 3 shared memory segments.The
mm->locked_vm within the process' task structure would be incremented
correctly to show the number of pages that are allocated to host these
   shared memory pages allocated by this process.
2. Then, run the "shmreget" test program to remove the above segments
and subsequently re-allocate one more. This would result in the
following update to the mm->locked_vm field:
* process starts with mm->locked_vm=0.
* process issues IPC_RMID op three times, the "minus" operations would
result mm->locked_vm to become a huge unsigned int (0xfffffff9 in my
test run / negative if viewed as int).
* process issues SHM_LOCK call, it will fail in #768
(linux-2.4.21-23.EL/mm/shmem.c) since locked is is a huge unsigned int
(negative/0xfffffff8):

   761         if (lock && !info->locked) {
   762                 locked = inode->i_size >> PAGE_SHIFT;
   763                 locked += mm->locked_vm;
   764                 lock_limit =
current->rlim[RLIMIT_MEMLOCK].rlim_cur;
   765                 lock_limit >>= PAGE_SHIFT;
   766                 if (locked > lock_limit && !capable(CAP_IPC_LOCK))
   767                         goto out_nomem;
   768                 if (locked > num_physpages/10*9)
   769                         goto out_nomem;
   770                 mm->locked_vm = locked;

Have a test kernel for the customer to work around this issue. For the
real fix, I would suggest back port 2.6 implementation into 2.4 but it
 will break KABI.



Version-Release number of selected component (if applicable):
kernel-2.4.21-26.ELsmp

How reproducible:
Always

Steps to Reproduce:
(see the problem description - test programs will be uploaded.
    

Additional info:
Comment 1 Wendy Cheng 2004-11-18 12:09:13 EST
Created attachment 106967 [details]
test program

1. Untar the file (tar xvf shmtest.tar) and build the two executables (shmget
and shmreget) by "make".  
2. Run the ./shmget to obtain three shared memory regions.
3. Run the ./shmreget to remove the above regions and get a new one.

The 3) would fail with ENOMEM.
Comment 3 Wendy Cheng 2004-11-18 12:34:31 EST
Created attachment 106970 [details]
wor around patch

This is the "better-than-before" patch that goes with the test kernel sent to
the customer. 

Also thought about changing the locked_vm into "int" instead of "unsigned int".
I eventually gave it up since the kernel had been doing too many shift (<< or
>>) operations that is cumbersome to get it right.  

Still, the 2.6 implementation looks most reasonable, except the KABI issue.
Comment 4 Rik van Riel 2004-11-18 13:08:38 EST
Yes, kABI needs to be broken in order for this bug to be fixed. 
That's going to have to be a decision for PM to make.
Comment 5 Ernie Petrides 2004-11-18 16:46:00 EST
This is a dup of bug 126411, but I'm leaving it open and
putting it on the KABI-blocker list.
Comment 6 Ernie Petrides 2005-06-06 19:54:31 EDT
A fix for this problem was committed to the RHEL3 U6 patch pool
on 4-May-2005 (in kernel version 2.4.21-32.3.EL) and to the RHEL3
E6 patch pool on 16-May-2005 (in kernel version 2.4.21-32.0.1.EL).

Following is the Errata System notice about the release fixing this:

"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."


*** This bug has been marked as a duplicate of 126411 ***

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