On Thu, Sep 13, 2012 at 02:27:33AM -0400, Jan Stancek wrote:
>
>
> ----- Original Message -----
> > From: "David Gibson" <da...@gibson.dropbear.id.au>
> > To: "Jan Stancek" <jstan...@redhat.com>
> > Cc: libhugetlbfs-devel@lists.sourceforge.net, an...@redhat.com
> > Sent: Thursday, 13 September, 2012 3:37:39 AM
> > Subject: Re: [Libhugetlbfs-devel] [PATCH] fail test only when MAP_FIXED
> > fails on free slices
> >
> > 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.
>
> One way which increases chances is rebuilding these testcases with -static,
> but I'm not sure how safe this is given this comment in tests/Makefile:
> "Can be changed once libhugetlbfs has better support for static linking"
Ah, that's a good idea. The problems with libhugetlbfs and -static,
AFAIR, are to do with the segement remapping and heap remapping
features. Since this testcase only uses explicit mapping, it should
be fine with -static.
> I tried rebuilding it and it worked without issues for me
> (./obj64/straddle_4GB_static):
>
> 10000000-100d0000 r-xp 00000000 fd:01 2759653
> /root/libhugetlbfs/tests/obj64/straddle_4GB_static
> 100d0000-100f0000 rw-p 000c0000 fd:01 2759653
> /root/libhugetlbfs/tests/obj64/straddle_4GB_static
> 100f0000-10100000 rw-p 00000000 00:00 0
> 10029590000-100295c0000 rw-p 00000000 00:00 0 [heap]
> fff7e180000-fff7e190000 rw-p 00000000 00:00 0
> fff7e190000-fff7e1b0000 r-xp 00000000 00:00 0 [vdso]
> fffd8740000-fffd8770000 rw-p 00000000 00:00 0 [stack]
>
> Mapping without MAP_FIXED at ff000000...done
> Clearing below 4GB...done
> Clearing above 4GB...done
> Mapping with MAP_FIXED at ff000000...done
> Clearing below 4GB...done
> Clearing above 4GB...done
> Tested above 4GB
> PASS
>
> Regards,
> Jan
>
> >
>
--
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
