[LTP] mmapstress03 weirdness? (fwd)

[LTP] mmapstress03 weirdness? (fwd)

[Geert Uytterhoeven]

---------- Forwarded message ----------
Date: Wed, 16 Sep 2009 18:37:12 +0200 (CEST)
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To: Linux Test Project <Ltp-list@lists.sourceforge.net>
Subject: [LTP] mmapstress03 weirdness?

On ppc64, with 32-bit userland, I get:

| Running tests.......
| <<<test_start>>>
| tag=mmapstress03 stime=1253117251
| cmdline="mmapstress03"
| contacts=""
| analysis=exit
| <<<test_output>>>
| incrementing stop
| : errno = 0: really large mmap didn't fail
| mmapstress03    1  TFAIL  :  Test failed
                     ^^^^^^^^^^^^^^^^^^^^^
| <<<execution_status>>>
| initiation_status="ok"
| duration=0 termination_type=exited termination_id=0 corefile=no
| cutime=0 cstime=0
| <<<test_end>>>
| INFO: ltp-pan reported all tests PASS
                                   ^^^^

The core part of this test is:

        /* Ask for a ridiculously large mmap region at a high address */
        if (mmap((caddr_t)(1UL << (POINTER_SIZE  - 1)) - pagesize,
                (size_t)((1UL << (POINTER_SIZE - 1)) - pagesize),
                PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_FIXED|MAP_SHARED, 0, 0)
                != (caddr_t)-1)
        {
                ERROR("really large mmap didn't fail");
                anyfail();
        }
        if (errno != ENOMEM && errno != EINVAL) {
                ERROR("really large mmap didn't set errno = ENOMEM nor EINVAL");
                anyfail();
        }

With 32-bit userland, this boils down to:

| mmap addr 0x7fff0000 size 0x7fff0000
| mmap returned 0x7fff0000

i.e. mmap() succeeds, but (1) the test expects it to fail, so the test returns
TFAIL, but (2) ltp-pan still reports that the tests passed?

In addition, sometimes mmapstress03 fails due to SEGV. I created a small test
program that just does the above mmap(), and depending on the distro and what
else I print later it crashes with a SEGV, too. Probably this happens because
the mmap() did succeed, and corrupted some existing mappings, cfr. the notes
for MAP_FIXED:

       MAP_FIXED
              Don’t  interpret  addr  as  a hint: place the mapping at exactly
              that address.  addr must be a multiple of the page size.  If the
              memory  region  specified  by addr and len overlaps pages of any
              existing mapping(s), then the overlapped part  of  the  existing
              mapping(s)  will  be discarded.  If the specified address cannot
              be used, mmap() will fail.  Because requiring  a  fixed  address
              for  a  mapping is less portable, the use of this option is dis‐
              couraged.


JFYI, with 64-bit userland, this boils down to:

| mmap addr 0x7fffffffffff0000 size 0x7fffffffffff0000
| mmap returned 0xffffffffffffffff

i.e. mmap() fails as expected, and the test succeeds.

Does all of this sound OK?
Thanks for your comments!

With kind regards,

Geert Uytterhoeven
Software Architect
Techsoft Centre

Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: [LTP] mmapstress03 weirdness? (fwd)

[Segher Boessenkool]

>         if (mmap((caddr_t)(1UL << (POINTER_SIZE  - 1)) - pagesize,
>                 (size_t)((1UL << (POINTER_SIZE - 1)) - pagesize),
>                 PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_FIXED| 
> MAP_SHARED, 0, 0)
>                 != (caddr_t)-1)

> With 32-bit userland, this boils down to:
>
> | mmap addr 0x7fff0000 size 0x7fff0000
> | mmap returned 0x7fff0000
>
> i.e. mmap() succeeds,

Yes, on a powerpc64 kernel, every 32-bit userspace process has 4GB
available (well, except the lowest few pages).  The process text sits
normally at 1M and the shared libs around 256M.

> but (1) the test expects it to fail, so the test returns
> TFAIL,

That's a bug in the test then.

> but (2) ltp-pan still reports that the tests passed?

Sounds like another bug.

> In addition, sometimes mmapstress03 fails due to SEGV. I created a  
> small test
> program that just does the above mmap(), and depending on the  
> distro and what
> else I print later it crashes with a SEGV, too. Probably this  
> happens because
> the mmap() did succeed, and corrupted some existing mappings,

It probably killed the stack, which sits all the way up near 4G.

> JFYI, with 64-bit userland, this boils down to:
>
> | mmap addr 0x7fffffffffff0000 size 0x7fffffffffff0000
> | mmap returned 0xffffffffffffffff
>
> i.e. mmap() fails as expected, and the test succeeds.

It tries to map space that is reserved for the kernel (c000...)

> Does all of this sound OK?

Seems to me everything works fine, except the tests themselves.


Segher

Re: [LTP] mmapstress03 weirdness? (fwd)

[Benjamin Herrenschmidt]

On Mon, 2009-09-21 at 15:40 +0200, Geert Uytterhoeven wrote:

> 
> With 32-bit userland, this boils down to:
> 
> | mmap addr 0x7fff0000 size 0x7fff0000
> | mmap returned 0x7fff0000
> 
> i.e. mmap() succeeds, but (1) the test expects it to fail, so the test returns
> TFAIL, but (2) ltp-pan still reports that the tests passed?

What is the output of /proc/<pid>/maps after that mmap ?

With a 64-bit kernel, 32-bit userspace has access to the entire 4G
address space, so mapping 2G-64k at the 2G-64k point can work, provided
you aren't overlapping an existing mapping such as the stack.

> In addition, sometimes mmapstress03 fails due to SEGV. I created a small test
> program that just does the above mmap(), and depending on the distro and what
> else I print later it crashes with a SEGV, too. Probably this happens because
> the mmap() did succeed, and corrupted some existing mappings, cfr. the notes
> for MAP_FIXED:

That's possible.

>        MAP_FIXED
>               Don’t  interpret  addr  as  a hint: place the mapping at exactly
>               that address.  addr must be a multiple of the page size.  If the
>               memory  region  specified  by addr and len overlaps pages of any
>               existing mapping(s), then the overlapped part  of  the  existing
>               mapping(s)  will  be discarded.  If the specified address cannot
>               be used, mmap() will fail.  Because requiring  a  fixed  address
>               for  a  mapping is less portable, the use of this option is dis‐
>               couraged.

Yeah, I suppose the test might be wiping out its own stack for example

IE. I think that test is just bogus :-)

> JFYI, with 64-bit userland, this boils down to:
> 
> | mmap addr 0x7fffffffffff0000 size 0x7fffffffffff0000
> | mmap returned 0xffffffffffffffff
> 
> i.e. mmap() fails as expected, and the test succeeds.

Right because on 64-bit userspace, you only are allowed something like
16T of address space.

> Does all of this sound OK?
> Thanks for your comments!

Yes, I think so far, it's just bogus tests :-)

Cheers,
Ben.

> With kind regards,
> 
> Geert Uytterhoeven
> Software Architect
> Techsoft Centre
> 
> Technology and Software Centre Europe
> The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
> 
> Phone:    +32 (0)2 700 8453
> Fax:      +32 (0)2 700 8622
> E-mail:   Geert.Uytterhoeven@sonycom.com
> Internet: http://www.sony-europe.com/
> 
> A division of Sony Europe (Belgium) N.V.
> VAT BE 0413.825.160 · RPR Brussels
> Fortis · BIC GEBABEBB · IBAN BE41293037680010
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [LTP] mmapstress03 weirdness? (fwd)

[Geert Uytterhoeven]

On Tue, 22 Sep 2009, Benjamin Herrenschmidt wrote:
> On Mon, 2009-09-21 at 15:40 +0200, Geert Uytterhoeven wrote:
> > With 32-bit userland, this boils down to:
> > | mmap addr 0x7fff0000 size 0x7fff0000
> > | mmap returned 0x7fff0000
> > 
> > i.e. mmap() succeeds, but (1) the test expects it to fail, so the test returns
> > TFAIL, but (2) ltp-pan still reports that the tests passed?
> 
> What is the output of /proc/<pid>/maps after that mmap ?

| 00100000-00120000 r-xp 00100000 00:00 0                                  [vdso]
| 0f470000-0f5d0000 r-xp 00000000 03:03 56852565                           /lib/libc-2.5.so
| 0f5d0000-0f5e0000 r--p 00160000 03:03 56852565                           /lib/libc-2.5.so
| 0f5e0000-0f5f0000 rw-p 00170000 03:03 56852565                           /lib/libc-2.5.so
| 0ffc0000-0ffe0000 r-xp 00000000 03:03 56852482                           /lib/ld-2.5.so
| 0ffe0000-0fff0000 r--p 00010000 03:03 56852482                           /lib/ld-2.5.so
| 0fff0000-10000000 rw-p 00020000 03:03 56852482                           /lib/ld-2.5.so
| 10000000-10010000 r-xp 00000000 03:03 65571126                           /tmp/a.out
| 10010000-10020000 rw-p 00000000 03:03 65571126                           /tmp/a.out
| 7fff0000-fffe0000 rw-s 00000000 00:09 5580806                            /dev/zero (deleted)

I.e. the big mmap() took out the stack mapping, which was previously at:

| ffa00000-ffb50000 rw-p ffa00000 00:00 0                                  [stack]

> With a 64-bit kernel, 32-bit userspace has access to the entire 4G
> address space, so mapping 2G-64k at the 2G-64k point can work, provided
> you aren't overlapping an existing mapping such as the stack.
> 
> > In addition, sometimes mmapstress03 fails due to SEGV. I created a small test
> > program that just does the above mmap(), and depending on the distro and what
> > else I print later it crashes with a SEGV, too. Probably this happens because
> > the mmap() did succeed, and corrupted some existing mappings, cfr. the notes
> > for MAP_FIXED:
> 
> That's possible.
> 
> >        MAP_FIXED
> >               Don’t  interpret  addr  as  a hint: place the mapping at exactly
> >               that address.  addr must be a multiple of the page size.  If the
> >               memory  region  specified  by addr and len overlaps pages of any
> >               existing mapping(s), then the overlapped part  of  the  existing
> >               mapping(s)  will  be discarded.  If the specified address cannot
> >               be used, mmap() will fail.  Because requiring  a  fixed  address
> >               for  a  mapping is less portable, the use of this option is dis‐
> >               couraged.
> 
> Yeah, I suppose the test might be wiping out its own stack for example

Indeed.

> IE. I think that test is just bogus :-)
> 
> > JFYI, with 64-bit userland, this boils down to:
> > 
> > | mmap addr 0x7fffffffffff0000 size 0x7fffffffffff0000
> > | mmap returned 0xffffffffffffffff
> > 
> > i.e. mmap() fails as expected, and the test succeeds.
> 
> Right because on 64-bit userspace, you only are allowed something like
> 16T of address space.
> 
> > Does all of this sound OK?
> > Thanks for your comments!
> 
> Yes, I think so far, it's just bogus tests :-)

Thanks for the confirmation, Segher and Ben!

With kind regards,

Geert Uytterhoeven
Software Architect
Techsoft Centre

Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010