From: Michal Hocko <miso@dhcp22.suse.cz>
To: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
linux-mm@kvack.org, Michal Hocko <mhocko@suse.cz>
Subject: [PATCH 1/2] mmap.2: clarify MAP_LOCKED semantic
Date: Wed, 13 May 2015 16:38:11 +0200 [thread overview]
Message-ID: <1431527892-2996-2-git-send-email-miso@dhcp22.suse.cz> (raw)
In-Reply-To: <1431527892-2996-1-git-send-email-miso@dhcp22.suse.cz>
From: Michal Hocko <mhocko@suse.cz>
MAP_LOCKED had a subtly different semantic from mmap(2)+mlock(2) since
it has been introduced.
mlock(2) fails if the memory range cannot get populated to guarantee
that no future major faults will happen on the range. mmap(MAP_LOCKED) on
the other hand silently succeeds even if the range was populated only
partially.
Fixing this subtle difference in the kernel is rather awkward because
the memory population happens after mm locks have been dropped and so
the cleanup before returning failure (munlock) could operate on something
else than the originally mapped area.
E.g. speculative userspace page fault handler catching SEGV and doing
mmap(fault_addr, MAP_FIXED|MAP_LOCKED) might discard portion of a racing
mmap and lead to lost data. Although it is not clear whether such a
usage would be valid, mmap page doesn't explicitly describe requirements
for threaded applications so we cannot exclude this possibility.
This patch makes the semantic of MAP_LOCKED explicit and suggest using
mmap + mlock as the only way to guarantee no later major page faults.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
---
man2/mmap.2 | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/man2/mmap.2 b/man2/mmap.2
index 54d68cf87e9e..1486be2e96b3 100644
--- a/man2/mmap.2
+++ b/man2/mmap.2
@@ -235,8 +235,19 @@ See the Linux kernel source file
for further information.
.TP
.BR MAP_LOCKED " (since Linux 2.5.37)"
-Lock the pages of the mapped region into memory in the manner of
+Mark the mmaped region to be locked in the same way as
.BR mlock (2).
+This implementation will try to populate (prefault) the whole range but
+the mmap call doesn't fail with
+.B ENOMEM
+if this fails. Therefore major faults might happen later on. So the semantic
+is not as strong as
+.BR mlock (2).
+.BR mmap (2)
++
+.BR mlock (2)
+should be used when major faults are not acceptable after the initialization
+of the mapping.
This flag is ignored in older kernels.
.\" If set, the mapped pages will not be swapped out.
.TP
--
2.1.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-05-13 14:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 14:38 [PATCH 0/2] man-pages: " Michal Hocko
2015-05-13 14:38 ` Michal Hocko [this message]
2015-05-13 14:45 ` [PATCH 1/2] mmap.2: " Eric B Munson
2015-05-13 14:48 ` Eric B Munson
2015-05-14 8:01 ` Michal Hocko
2015-05-14 13:36 ` Michael Kerrisk (man-pages)
2016-05-11 11:07 ` Peter Zijlstra
2016-05-11 11:18 ` Peter Zijlstra
2016-05-11 11:32 ` Michal Hocko
2015-05-13 14:38 ` [PATCH 2/2] mmap2: clarify MAP_POPULATE Michal Hocko
2015-05-13 14:47 ` Eric B Munson
2015-05-14 13:36 ` Michael Kerrisk (man-pages)
2015-05-15 0:13 ` David Rientjes
2015-05-18 9:12 ` [PATCH 0/2] man-pages: clarify MAP_LOCKED semantic Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1431527892-2996-2-git-send-email-miso@dhcp22.suse.cz \
--to=miso@dhcp22.suse.cz \
--cc=akpm@linux-foundation.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=mtk.manpages@gmail.com \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox