On Wed, Sep 12, 2012 at 12:02:46PM +0200, Jan Stancek wrote:
> huge_at_4GB_normal_below, huge_below_4GB_normal_above, straddle_4GB
> are tests to test corner cases on powerpc. powerpc manages memory
> using slices: low (0-4G) and high (4G-).
>
> These tests are using MAP_FIXED and try to mmap hugepage at various
> locations. Issue is that kernel or ld.so can be already using region
> that these tests want to use. At the moment it ends with failure:
> # ./obj64/straddle_4GB
> Starting testcase "./obj64/straddle_4GB", pid 25949
> Mapping without MAP_FIXED at ff000000...got 0xefffe000000 instead, never
> mind
> Mapping with MAP_FIXED at ff000000
> FAIL mmap() FIXED failed: Device or resource busy
>
> Looking at mappings prior to failed mmap, there are already some libraries
> mapped to first high slice (0).
>
> 10010000-10020000 r--p 00000000 fd:01 2893006
> /root/libhugetlbfs/tests/obj64/straddle_4GB
> 10020000-10030000 rw-p 00010000 fd:01 2893006
> /root/libhugetlbfs/tests/obj64/straddle_4GB
> 8015160000-8015190000 r-xp 00000000 fd:01 1857222 /usr/lib64/ld-2.15.so
> 8015190000-80151a0000 r--p 00020000 fd:01 1857222 /usr/lib64/ld-2.15.so
> 80151a0000-80151b0000 rw-p 00030000 fd:01 1857222 /usr/lib64/ld-2.15.so
> 80151d0000-8015390000 r-xp 00000000 fd:01 1857223 /usr/lib64/libc-2.15.so
> 8015390000-80153a0000 r--p 001b0000 fd:01 1857223 /usr/lib64/libc-2.15.so
> 80153a0000-80153c0000 rw-p 001c0000 fd:01 1857223 /usr/lib64/libc-2.15.so
> 80153c0000-80153e0000 r-xp 00000000 fd:01 1835789
> /usr/lib64/libpthread-2.15.so
> 80153e0000-80153f0000 r--p 00010000 fd:01 1835789
> /usr/lib64/libpthread-2.15.so
> 80153f0000-8015400000 rw-p 00020000 fd:01 1835789
> /usr/lib64/libpthread-2.15.so
> 8015400000-8015410000 r-xp 00000000 fd:01 1842374 /usr/lib64/libdl-2.15.so
> 8015410000-8015420000 r--p 00000000 fd:01 1842374 /usr/lib64/libdl-2.15.so
> 8015420000-8015430000 rw-p 00010000 fd:01 1842374 /usr/lib64/libdl-2.15.so
> 10022e00000-10022e30000 rw-p 00000000 00:00 0 [heap]
> fff8e650000-fff8e670000 r-xp 00000000 fd:01 1837902
> /usr/lib64/libhugetlbfs.so
> fff8e670000-fff8e680000 r--p 00010000 fd:01 1837902
> /usr/lib64/libhugetlbfs.so
> fff8e680000-fff8e690000 rw-p 00020000 fd:01 1837902
> /usr/lib64/libhugetlbfs.so
> fff8e690000-fff8e6a0000 r-xp 00000000 fd:01 1842940
> /usr/lib64/libhugetlbfs_privutils.so
> fff8e6a0000-fff8e6b0000 r--p 00000000 fd:01 1842940
> /usr/lib64/libhugetlbfs_privutils.so
> fff8e6b0000-fff8e6c0000 rw-p 00010000 fd:01 1842940
> /usr/lib64/libhugetlbfs_privutils.so
> fff8e6c0000-fff8e6d0000 rw-p 00000000 00:00 0
> fff8e6d0000-fff8e6f0000 r-xp 00000000 00:00 0 [vdso]
> fffc7110000-fffc7140000 rw-p 00000000 00:00 0 [stack]
>
> This patch checks that slices used by tests are actually free (not mapped).
> If they are not free and mmap fails, test will PASS as inconclusive.
Hrm. Pass inconculsive really isn't the right result here - that
indicates that we tested as best we could, but we can't eliminate the
possibility that we passed only by luck. In this case we were unable
to test at all.
It's a bit of a pain, really, because these were realy bugs and they
are still edge cases with interesting complexities and therefore
likely sites for bugs. I'm not sure how to get around this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
------------------------------------------------------------------------------
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/
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
