Messages in this thread | | | From | Segher Boessenkool <> | Subject | Re: [LTP] mmapstress03 weirdness? (fwd) | Date | Mon, 21 Sep 2009 18:10:32 +0200 |
| |
> 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
| |