Hi,
Please find below a configuration error reported by Santwana, and, then
the fix for the same by Amit:
========================================================================================
---Problem Description---
Configuration error in mlockall02.
mlockall02 did not BEHAVE as expected.
---uname output---
Linux 2.6.18-53.el5xen #1 SMP Wed Oct 10 16:48:44 EDT 2007 x86_64 x86_64 x86_64
GNU/Linux
Machine Type = e326m
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1.Copy and untar ltp testsuite.
2.Issue make followed by make install.
3.Go to testcases/kernel/syscalls/mlockall directory inside the ltp test suite.
4.Run mlockall02 by issuing ./mlockall02.
5.It produces configuration error as :
"mlockall02 1 CONF : mlockall02 did not BEHAVE as expected.This may be
okay if you are running Red Hat Enterprise Linux 3 (RHEL)".
I verified this issue on various architecture like ia64, ppc64, x86_64 and on
different distro's like sles10, fc7, sles9, rhel5 and rhel4 and in all the above
fields this issue was reproducible.
Thanks
Santwana,
========================================================================================
========================================================================================
Amitś Investigation below:
Here is the output of mlockall02 :
# ./mlockall02
mlockall02 1 CONF : mlockall02 did not BEHAVE as expected.This may be okay
if you are running Red Hat Enterprise Linux 3 (RHEL)
mlockall02 2 CONF : mlockall02 did not BEHAVE as expected.This may be okay
if you are running Red Hat Enterprise Linux 3 (RHEL)
mlockall02 3 PASS : expected failure - errno = 22 : Invalid argument
#
I had a quick look at the man page and it says this :
"In Linux kernels before 2.6.9, this limit controlled the amount of memory
that could be locked by a privileged process. Since Linux 2.6.9, no limits
are placed on the amount of memory that a privileged process may lock, and this
limit instead governs the amount of memory that an unprivileged process may
lock."
But, in the CASE 1 above, we are calling mlockall as super user. Hence it did
pass. If I do a "seteuid" to some other user (say, nobody user id), it works as
expected (i.e. as mentioned in the man page) and the testcase also passes. Hence
this is a testcase issue.
Ok. The second problem is also testcase issue.
The current expected behavior is true for kernel 2.6.8 and below. The behavior
changes from 2.6.9. Here is what man page of mlockall says :
ERRORS
ENOMEM (Linux 2.6.9 and later) the caller had a non-zero RLIMIT_MEMLOCK
soft resource limit, but tried to
lock more memory than the limit permitted. This limit is not
enforced if the process is privileged
(CAP_IPC_LOCK).
ENOMEM (Linux 2.4 and earlier) the calling process tried to lock more
than half of RAM.
EPERM (Linux 2.6.9 and later) the caller was not privileged
(CAP_IPC_LOCK) and its RLIMIT_MEMLOCK soft
resource limit was 0.
EPERM (Linux 2.6.8 and earlier) The calling process has
insufficient privilege to call munlockall().
Under Linux the CAP_IPC_LOCK capability is required.
This patch should fix the problem. It also takes care of the different
expectations on different kernel levels (i.e. before and after 2.6.9); as per
the man page of mlockall02.
Please test and update. Thanks!
========================================================================================
========================================================================================
--Subrata
diff -Nuarp ltp-full-20071130.org/testcases/kernel/syscalls/mlockall/mlockall02.c ltp-full-20071130/testcases/kernel/syscalls/mlockall/mlockall02.c
--- ltp-full-20071130.org/testcases/kernel/syscalls/mlockall/mlockall02.c 2007-12-27 04:12:59.000000000 -0500
+++ ltp-full-20071130/testcases/kernel/syscalls/mlockall/mlockall02.c 2007-12-27 04:16:37.000000000 -0500
@@ -196,7 +196,8 @@ int setup_test(int i)
switch(i) {
case 0:
- rl.rlim_max = 10; rl.rlim_cur = 7;
+ rl.rlim_max = 10;
+ rl.rlim_cur = 7;
if (setrlimit(RLIMIT_MEMLOCK, &rl) != 0)
{
@@ -205,8 +206,31 @@ int setup_test(int i)
"for mlockall error %s\n", TC[i].edesc);
return 1;
}
+ if (tst_kvercmp(2,6,9) >= 0) {
+ ltpuser = getpwnam(nobody_uid);
+ if (seteuid(ltpuser->pw_uid) == -1) {
+ tst_brkm(TBROK, cleanup,"seteuid() "
+ "failed to change euid to %d "
+ "errno = %d : %s",
+ ltpuser->pw_uid, TEST_ERRNO,
+ strerror(TEST_ERRNO));
+ return 1;
+ }
+ }
return 0;
case 1:
+ if (tst_kvercmp(2,6,9) >= 0) {
+ rl.rlim_max = 0;
+ rl.rlim_cur = 0;
+ if (setrlimit(RLIMIT_MEMLOCK, &rl) != 0)
+ {
+ tst_resm(TWARN, "setrlimit failed to "
+ "set the resource for "
+ "RLIMIT_MEMLOCK to check for "
+ "mlockall error %s\n", TC[i].edesc);
+ return 1;
+ }
+ }
ltpuser = getpwnam(nobody_uid);
if (seteuid(ltpuser->pw_uid) == -1) {
tst_brkm(TBROK, cleanup,"seteuid() failed to "
@@ -226,6 +250,9 @@ void cleanup_test(int i)
switch(i) {
case 0:
+ if (tst_kvercmp(2,6,9) >= 0)
+ seteuid(0);
+
rl.rlim_max = -1; rl.rlim_cur = -1;
if (setrlimit(RLIMIT_MEMLOCK, &rl) != 0)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
