]> git.ipfire.org Git - thirdparty/valgrind.git/commitdiff
Improve mmap MAP_HUGETLB support.
authorFlorian Krohm <florian@eich-krohm.de>
Thu, 13 Aug 2015 20:35:03 +0000 (20:35 +0000)
committerFlorian Krohm <florian@eich-krohm.de>
Thu, 13 Aug 2015 20:35:03 +0000 (20:35 +0000)
This is a follow up to r14682:

When an mmap retry is done without any constraints, the kernel can
place it into free or reservation segments (i.e. anywhere there is no
mapping yet).
In r14682 a sanity check made the hypothesis that the new mapping was
in a free segment, but it does not hold at least on Linux 3.12 and 3.16
on amd64 (tested under Debian).
There is no risk in allowing the mapping to end up in (what was
previously) a reservation at this point, because it is also allowed.

Patch by Guillaume Knispel <xilun0@gmail.com>. Fixes BZ #348269.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15538

NEWS
coregrind/m_syswrap/syswrap-generic.c
docs/internals/3_10_BUGSTATUS.txt

diff --git a/NEWS b/NEWS
index 69bfdfae3c77d075266c20926d563586431b2490..b37e87b1f77063124ed2925c595b20582369aa1c 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -267,6 +267,7 @@ where XXXXXX is the bug number as listed below.
         == 345929
 348102  Patch updating v4l2 API support
 348247  jno jumps wrongly when overflow is not set
+348269  Improve mmap MAP_HUGETLB support.
 348565  Fix detection of command line option availability for clang
 348728  Fix broken check for VIDIOC_G_ENC_INDEX
 348748  Fix redundant condition
index 051ab273c6012bfd067ae3c82ea4f7bcb3b451f9..b89746064ea60f004a23fdd0d965a40a6d2b235c 100644 (file)
@@ -2323,9 +2323,9 @@ ML_(generic_PRE_sys_mmap) ( ThreadId tid,
       to understand special file system mount options).
       So, let's just redo an mmap, without giving any constraint to
       the kernel. If that succeeds, check with aspacem that the returned
-      address is acceptable (i.e. is free).
+      address is acceptable.
       This will give a similar effect as if the user would have
-      specified a MAP_FIXED at that address.
+      hinted that address.
       The aspacem state will be correctly updated afterwards.
       We however cannot do this last refinement when the user asked
       for a fixed mapping, as the user asked a specific address. */
@@ -2337,8 +2337,18 @@ ML_(generic_PRE_sys_mmap) ( ThreadId tid,
                                        arg4,
                                        arg5, arg6);
       if (!sr_isError(sres)) {
-         vg_assert(VG_(am_covered_by_single_free_segment)((Addr)sr_Res(sres),
-                                                           arg2));
+         /* The kernel is supposed to know what it is doing, but let's
+            do a last sanity check anyway, as if the chosen address had
+            been initially hinted by the client. The whole point of this
+            last try was to allow mmap of huge pages to succeed without
+            making aspacem understand them, on the other hand the kernel
+            does not know about valgrind reservations, so this mapping
+            can end up in free space and reservations. */
+         mreq.start = (Addr)sr_Res(sres);
+         mreq.len   = arg2;
+         mreq.rkind = MHint;
+         advised = VG_(am_get_advisory)( &mreq, True/*client*/, &mreq_ok );
+         vg_assert(mreq_ok && advised == mreq.start);
       }
    }
 
index a9d18708956a1081ef43014c21a02ac5684f577a..18a06a577ae745d2d9277752c142b978edd4b210 100644 (file)
@@ -144,8 +144,6 @@ go in here.
 
 345414  WARNING: unhandled syscall: 317 (sys_seccomp)
 
-348269  support of mmap for huge pages is broken at least on amd64
-
 348616  Wine/valgrind: Warning: noted but unhandled ioctl 0x5390 with
         no size/direction hints. (DVD_READ_STRUCT)