* [LTP] [PATCH]page numbers should be decreased to 1 in vma01 test
@ 2012-04-28 5:15 hejianet
2012-06-25 7:38 ` Caspar Zhang
0 siblings, 1 reply; 2+ messages in thread
From: hejianet @ 2012-04-28 5:15 UTC (permalink / raw)
To: ltp-list
Hi all
testcases/kernel/mem/vma/vma01.c is to test the result of
find_mergeable_anon_vma()
In my opinion, it is not correct in some architectures
1)some architectures(eg.ppcnf) use *bottomup* vma layout instead of
*topdown*
so vma01 test should be masked in those architectures.
2)even in the *topdown* architectures, there is a potential issure.
I will give an example to show why the pagesize should be decreased from
3 to 1
a.out is an elf file compiled from vma01.c with minor revision.
>-bash-4.1# strace -f ./a.out
>execve("./a.out", ["./a.out"], [/* 22 vars */]) = 0
>brk(0) = 0x10012000
>mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x47ffd000
>access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
>open("/etc/ld.so.cache", O_RDONLY) = 3
>fstat64(3, {st_mode=S_IFREG|0644, st_size=12875, ...}) = 0
>mmap(NULL, 12875, PROT_READ, MAP_PRIVATE, 3, 0) = 0x47ff9000
>close(3) = 0
>open("/lib/libc.so.6", O_RDONLY) = 3
>read(3,
"\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\351\354\0\0\0004"...,
512) = 512
>fstat64(3, {st_mode=S_IFREG|0755, st_size=2015420, ...}) = 0
>mmap(0xfe2c000, 1848788, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfe2c000
>mprotect(0xffd2000, 90112, PROT_NONE) = 0
>mmap(0xffe8000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ac000) = 0xffe8000
>mmap(0xffed000, 9684, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffed000
>close(3) = 0
>mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x47ff8000
>mprotect(0xffe8000, 16384, PROT_READ) = 0
>mprotect(0x47ffe000, 4096, PROT_READ) = 0
>munmap(0x47ff9000, 12875) = 0
>mmap(NULL, 12288, PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x47ffa000
>clone(Process 698 attached
>child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x47ff8068) = 698
>[pid 697] waitpid(-1, <unfinished ...>
>[pid 698] mmap(0x47ffd000, 12288, PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x47ff5000
>[pid 698] fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0),
...}) = 0
>[pid 698] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x47ff9000
>[pid 698] write(1, "parent: t = 0x47ffa000\n", 23parent: t = 0x47ffa000
>) = 23
the symptom is when /etc/ld.so.cache is small, we never get a 2 3*ps
aligned pages.
we got the layout like this:
...
3*ps by children
1*ps
1*ps
3*ps by parent
...
summary: a) the mmap area for loading /etc/ld.so.cache is nearby the
normal mmap()
b) if the /etc/ld.so.cache is small, when it is unmmaped, there
is a small hole left for allocating later.
c) we couldn't make sure that the 3*ps will be alignedly
allocated if /etc/ld.so.cache is so small
conclusion: we need decrease the page number from 3 to 1 in vma01 test
--- testcases/kernel/mem/vma/vma01.c.ori 2012-04-28
12:51:16.453125000 +0800
+++ testcases/kernel/mem/vma/vma01.c 2012-04-28 12:53:35.375000000 +0800
@@ -92,7 +92,7 @@ static void check_vma(void)
int status;
void *t, *u, *x, *y;
- t = mmap(NULL, 3*ps, PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
+ t = mmap(NULL, 1*ps, PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
if (t == MAP_FAILED)
tst_brkm(TBROK|TERRNO, cleanup, "mmap");
memset(t, 1, ps);
@@ -102,7 +102,7 @@ static void check_vma(void)
tst_brkm(TBROK|TERRNO, cleanup, "fork");
case 0:
memset(t, 2, ps);
- u = mmap(t + 3*ps, 3*ps, PROT_WRITE,
+ u = mmap(t + 1*ps, 1*ps, PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
if (u == MAP_FAILED) {
perror("mmap failed.\n");
@@ -113,11 +113,11 @@ static void check_vma(void)
memset(u, 2, ps);
x = get_end_addr(u, MAPS_FILE);
- if (x == u + 6*ps)
+ if (x == u + 2*ps)
exit(1);
- if (x == u + 3*ps) {
+ if (x == u + 1*ps) {
y = get_end_addr(x, MAPS_FILE);
- if (y == x + 3*ps)
+ if (y == x + 1*ps)
exit(0);
}
exit(255);
@@ -157,10 +157,10 @@ static void check_status(int status)
{
switch (status) {
case 0:
- tst_resm(TPASS, "two 3*ps VMAs found.");
+ tst_resm(TPASS, "two 1*ps VMAs found.");
break;
case 1:
- tst_resm(TFAIL, "A single 6*ps VMA found.");
+ tst_resm(TFAIL, "A single 2*ps VMA found.");
break;
default:
tst_brkm(TBROK, cleanup, "unexpected VMA found.");
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [LTP] [PATCH]page numbers should be decreased to 1 in vma01 test
2012-04-28 5:15 [LTP] [PATCH]page numbers should be decreased to 1 in vma01 test hejianet
@ 2012-06-25 7:38 ` Caspar Zhang
0 siblings, 0 replies; 2+ messages in thread
From: Caspar Zhang @ 2012-06-25 7:38 UTC (permalink / raw)
To: hejianet; +Cc: ltp-list
On 04/28/2012 01:15 PM, hejianet wrote:
> Hi all
> testcases/kernel/mem/vma/vma01.c is to test the result of
> find_mergeable_anon_vma()
> In my opinion, it is not correct in some architectures
> 1)some architectures(eg.ppcnf) use *bottomup* vma layout instead of
> *topdown*
> so vma01 test should be masked in those architectures.
>
> 2)even in the *topdown* architectures, there is a potential issure.
> I will give an example to show why the pagesize should be decreased from
> 3 to 1
> a.out is an elf file compiled from vma01.c with minor revision.
>> -bash-4.1# strace -f ./a.out
>> execve("./a.out", ["./a.out"], [/* 22 vars */]) = 0
>> brk(0) = 0x10012000
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x47ffd000
>> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
>> open("/etc/ld.so.cache", O_RDONLY) = 3
>> fstat64(3, {st_mode=S_IFREG|0644, st_size=12875, ...}) = 0
>> mmap(NULL, 12875, PROT_READ, MAP_PRIVATE, 3, 0) = 0x47ff9000
>> close(3) = 0
>> open("/lib/libc.so.6", O_RDONLY) = 3
>> read(3,
> "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\351\354\0\0\0004"...,
> 512) = 512
>> fstat64(3, {st_mode=S_IFREG|0755, st_size=2015420, ...}) = 0
>> mmap(0xfe2c000, 1848788, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfe2c000
>> mprotect(0xffd2000, 90112, PROT_NONE) = 0
>> mmap(0xffe8000, 20480, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ac000) = 0xffe8000
>> mmap(0xffed000, 9684, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffed000
>> close(3) = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x47ff8000
>> mprotect(0xffe8000, 16384, PROT_READ) = 0
>> mprotect(0x47ffe000, 4096, PROT_READ) = 0
>> munmap(0x47ff9000, 12875) = 0
>> mmap(NULL, 12288, PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x47ffa000
>> clone(Process 698 attached
>> child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x47ff8068) = 698
>> [pid 697] waitpid(-1, <unfinished ...>
>> [pid 698] mmap(0x47ffd000, 12288, PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x47ff5000
>> [pid 698] fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0),
> ...}) = 0
>> [pid 698] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x47ff9000
>> [pid 698] write(1, "parent: t = 0x47ffa000\n", 23parent: t = 0x47ffa000
>> ) = 23
>
> the symptom is when /etc/ld.so.cache is small, we never get a 2 3*ps
> aligned pages.
> we got the layout like this:
> ...
> 3*ps by children
> 1*ps
> 1*ps
> 3*ps by parent
> ...
> summary: a) the mmap area for loading /etc/ld.so.cache is nearby the
> normal mmap()
> b) if the /etc/ld.so.cache is small, when it is unmmaped, there
> is a small hole left for allocating later.
> c) we couldn't make sure that the 3*ps will be alignedly
> allocated if /etc/ld.so.cache is so small
>
> conclusion: we need decrease the page number from 3 to 1 in vma01 test
Hi, thanks for the patch and sorry for (very very) late response due to
busying other things in past months...
I tried another approach in my PATCH 2/2, it creates a big hole to make
sure 2 3*ps can map successfully. I tried on my systems and it did work.
Could you try my patch 1/2 and 2/2 to see if it can solve your problem?
IIRC, reducing to 1*ps is a solution for this too, yet I've tried to see
if it can reproduce the bug we meet before.
Thanks,
Caspar
>
>
> --- testcases/kernel/mem/vma/vma01.c.ori 2012-04-28
> 12:51:16.453125000 +0800
> +++ testcases/kernel/mem/vma/vma01.c 2012-04-28 12:53:35.375000000 +0800
> @@ -92,7 +92,7 @@ static void check_vma(void)
> int status;
> void *t, *u, *x, *y;
>
> - t = mmap(NULL, 3*ps, PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
> + t = mmap(NULL, 1*ps, PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
> if (t == MAP_FAILED)
> tst_brkm(TBROK|TERRNO, cleanup, "mmap");
> memset(t, 1, ps);
> @@ -102,7 +102,7 @@ static void check_vma(void)
> tst_brkm(TBROK|TERRNO, cleanup, "fork");
> case 0:
> memset(t, 2, ps);
> - u = mmap(t + 3*ps, 3*ps, PROT_WRITE,
> + u = mmap(t + 1*ps, 1*ps, PROT_WRITE,
> MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
> if (u == MAP_FAILED) {
> perror("mmap failed.\n");
> @@ -113,11 +113,11 @@ static void check_vma(void)
> memset(u, 2, ps);
>
> x = get_end_addr(u, MAPS_FILE);
> - if (x == u + 6*ps)
> + if (x == u + 2*ps)
> exit(1);
> - if (x == u + 3*ps) {
> + if (x == u + 1*ps) {
> y = get_end_addr(x, MAPS_FILE);
> - if (y == x + 3*ps)
> + if (y == x + 1*ps)
> exit(0);
> }
> exit(255);
> @@ -157,10 +157,10 @@ static void check_status(int status)
> {
> switch (status) {
> case 0:
> - tst_resm(TPASS, "two 3*ps VMAs found.");
> + tst_resm(TPASS, "two 1*ps VMAs found.");
> break;
> case 1:
> - tst_resm(TFAIL, "A single 6*ps VMA found.");
> + tst_resm(TFAIL, "A single 2*ps VMA found.");
> break;
> default:
> tst_brkm(TBROK, cleanup, "unexpected VMA found.");
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-06-25 7:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-28 5:15 [LTP] [PATCH]page numbers should be decreased to 1 in vma01 test hejianet
2012-06-25 7:38 ` Caspar Zhang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox