[LTP] [PATCH] fix "hugeshmat01" test

[LTP] [PATCH] fix "hugeshmat01" test

[Mitani]

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

Hi,

I tried to run hugeshmat01 testcase, but it failed.
This testcase failed in following systems.
   - RHEL5.5-ia64
   - RHEL4.8-x86_64
   - RHEL4.8-ia64

I used latest git:
   ltp-dev-7c67a09a10268b5f9f503e0254f1f0f9f5ac2b69.tar.gz
This testcase failed also in previous gits.


RHEL5.5-ia64 log:
------------
hugeshmat01    1  TPASS  :  conditions and functionality are correct
hugeshmat01    2  TFAIL  :  hugeshmat01 call failed - errno = 22 : Invalid
argument
hugeshmat01    3  TBROK  :  Remaining cases broken
------------

It is caused by "EINVAL" failure of shmat().

---(hugeshmat01.c)---------
[...]
                for (i=0; i<TST_TOTAL; i++) {

                        /*
                         * Use TEST macro to make the call
                         */
                        errno = 0;
                        addr = shmat(*(TC[i].shmid), (void *)(TC[i].addr),
                                   TC[i].flags);
[...]
------------

In second loop (i=1), arguments of shemat() are followings:

   shmat(id, 0x10000000eee, SHM_RND)

This test expects that the return value of shmat() is rounded down to 
a multiple of SHMLBA.
But shmat() failed in some systems.
I deduced that "0x10000000eee" address may be outside of hugepages area.

So I used the return value of first loop's shmat() instead of fixed 
address ("0x10000000eee").
And the test succeeded.

Signed-off-by: Tomonori Mitani <mitani@ryobi.co.jp>

============
--- a/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c	2010-08-05
22:28:15.000000000 +0900
+++ b/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c	2010-08-06
15:19:05.000000000 +0900
@@ -67,6 +67,7 @@
 #define CASE0		10		/* values to write into the shared
*/
 #define CASE1		20		/* memory location.		
*/
 
+/* This value will be replaced in main() */
 #if __WORDSIZE==64
 #define UNALIGNED      0x10000000eee
 #else
@@ -124,6 +125,12 @@
 			 * Use TEST macro to make the call
 			 */
 			errno = 0;
+
+			/* When TC1, replace UNALIGNED to (TC0's addr +
0xeee) */
+			if (i == 1) {
+				TC[i].addr = addr + 0xeee;
+			}
+
 			addr = shmat(*(TC[i].shmid), (void *)(TC[i].addr),
 				   TC[i].flags);
 			TEST_ERRNO = errno;
============



Regards--


-Tomonori Mitani

[-- Attachment #2: hugeshmat01.patch --]
[-- Type: application/octet-stream, Size: 754 bytes --]

--- a/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c	2010-08-05 22:28:15.000000000 +0900
+++ b/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c	2010-08-06 15:19:05.000000000 +0900
@@ -67,6 +67,7 @@
 #define CASE0		10		/* values to write into the shared */
 #define CASE1		20		/* memory location.		   */
 
+/* This value will be replaced in main() */
 #if __WORDSIZE==64
 #define UNALIGNED      0x10000000eee
 #else
@@ -124,6 +125,12 @@
 			 * Use TEST macro to make the call
 			 */
 			errno = 0;
+
+			/* When TC1, replace UNALIGNED to (TC0's addr + 0xeee) */
+			if (i == 1) {
+				TC[i].addr = addr + 0xeee;
+			}
+
 			addr = shmat(*(TC[i].shmid), (void *)(TC[i].addr),
 				   TC[i].flags);
 			TEST_ERRNO = errno;

[-- Attachment #3: Type: text/plain, Size: 224 bytes --]

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] fix "hugeshmat01" test

[Garrett Cooper]

2010/8/9 Mitani <mitani@ryobi.co.jp>:
> Hi,
>
> I tried to run hugeshmat01 testcase, but it failed.
> This testcase failed in following systems.
>   - RHEL5.5-ia64
>   - RHEL4.8-x86_64
>   - RHEL4.8-ia64
>
> I used latest git:
>   ltp-dev-7c67a09a10268b5f9f503e0254f1f0f9f5ac2b69.tar.gz
> This testcase failed also in previous gits.
>
>
> RHEL5.5-ia64 log:
> ------------
> hugeshmat01    1  TPASS  :  conditions and functionality are correct
> hugeshmat01    2  TFAIL  :  hugeshmat01 call failed - errno = 22 : Invalid
> argument
> hugeshmat01    3  TBROK  :  Remaining cases broken
> ------------
>
> It is caused by "EINVAL" failure of shmat().
>
> ---(hugeshmat01.c)---------
> [...]
>                for (i=0; i<TST_TOTAL; i++) {
>
>                        /*
>                         * Use TEST macro to make the call
>                         */
>                        errno = 0;
>                        addr = shmat(*(TC[i].shmid), (void *)(TC[i].addr),
>                                   TC[i].flags);
> [...]
> ------------
>
> In second loop (i=1), arguments of shemat() are followings:
>
>   shmat(id, 0x10000000eee, SHM_RND)
>
> This test expects that the return value of shmat() is rounded down to
> a multiple of SHMLBA.
> But shmat() failed in some systems.
> I deduced that "0x10000000eee" address may be outside of hugepages area.
>
> So I used the return value of first loop's shmat() instead of fixed
> address ("0x10000000eee").
> And the test succeeded.

The question I have to pose is: why would it do this if the other
address was deallocated?

Thanks,
-Garrett

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] fix "hugeshmat01" test

[Mitani]

> -----Original Message-----
> From: Garrett Cooper [mailto:yanegomi@gmail.com]
> Sent: Friday, August 13, 2010 3:35 PM
> To: Mitani
> Cc: ltp-list@lists.sourceforge.net; 當座 健市
> Subject: Re: [LTP] [PATCH] fix "hugeshmat01" test
> 
> 2010/8/9 Mitani <mitani@ryobi.co.jp>:
> > Hi,
> >
> > I tried to run hugeshmat01 testcase, but it failed.
> > This testcase failed in following systems.
> >   - RHEL5.5-ia64
> >   - RHEL4.8-x86_64
> >   - RHEL4.8-ia64
> >
> > I used latest git:
> >   ltp-dev-7c67a09a10268b5f9f503e0254f1f0f9f5ac2b69.tar.gz
> > This testcase failed also in previous gits.
> >
> >
> > RHEL5.5-ia64 log:
> > ------------
> > hugeshmat01    1  TPASS  :  conditions and functionality are
> correct
> > hugeshmat01    2  TFAIL  :  hugeshmat01 call failed - errno = 22 :
> Invalid
> > argument
> > hugeshmat01    3  TBROK  :  Remaining cases broken
> > ------------
> >
> > It is caused by "EINVAL" failure of shmat().
> >
> > ---(hugeshmat01.c)---------
> > [...]
> >                for (i=0; i<TST_TOTAL; i++) {
> >
> >                        /*
> >                         * Use TEST macro to make the call
> >                         */
> >                        errno = 0;
> >                        addr = shmat(*(TC[i].shmid), (void
> *)(TC[i].addr),
> >                                   TC[i].flags);
> > [...]
> > ------------
> >
> > In second loop (i=1), arguments of shemat() are followings:
> >
> >   shmat(id, 0x10000000eee, SHM_RND)
> >
> > This test expects that the return value of shmat() is rounded down
> to
> > a multiple of SHMLBA.
> > But shmat() failed in some systems.
> > I deduced that "0x10000000eee" address may be outside of hugepages
> area.
> >
> > So I used the return value of first loop's shmat() instead of fixed
> > address ("0x10000000eee").
> > And the test succeeded.
> 
> The question I have to pose is: why would it do this if the other
> address was deallocated?
> 
> Thanks,
> -Garrett

Hi,

"hugeshmat01" test has three fase tests.
In these tests, second one failed in my several x64_64 and ia64 
architecture machines.

The first is the test for shmat() with 0 address in 2nd argument.
The second is the test for shmat() with unaligned address in 2nd argument.

In the first test, it is expected that 0 addressed shmat() returns 
with new aligned address.
In the second test, it is expected that unaligned addressed shmat()
returns with aligned address.

This second test uses the fixed address "0x10000000eee" for unaligned 
address.
When a fixed address was specified, this address may be the address 
which other processes use depending on a case. This may be out of 
user space.

The dynamic address gotten by the first test's shmget() is the address 
without such a risk, I think.
I performed this revision to reduce the risk of the second test 
by reusing a address gotten by the first test.


Thank you--

-Tomonori Mitani



------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list