From: Vlastimil Babka <vbabka@suse.cz>
To: Michal Hocko <mhocko@kernel.org>, Eric B Munson <emunson@akamai.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuahkh@osg.samsung.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Ralf Baechle <ralf@linux-mips.org>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mips@linux-mips.org, linux-parisc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, linux-mm@kvack.org,
linux-arch@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
Date: Wed, 29 Jul 2015 12:49:57 +0200 [thread overview]
Message-ID: <55B8AFD5.3030902@suse.cz> (raw)
In-Reply-To: <20150729104532.GE15801@dhcp22.suse.cz>
On 07/29/2015 12:45 PM, Michal Hocko wrote:
>> In a much less
>> likely corner case, it is not possible in the current setup to request
>> all current VMAs be VM_LOCKONFAULT and all future be VM_LOCKED.
>
> Vlastimil has already pointed that out. MCL_FUTURE doesn't clear
> MCL_CURRENT. I was quite surprised in the beginning but it makes a
> perfect sense. mlockall call shouldn't lead into munlocking, that would
> be just weird. Clearing MCL_FUTURE on MCL_CURRENT makes sense on the
> other hand because the request is explicit about _current_ memory and it
> doesn't lead to any munlocking.
Yeah after more thinking it does make some sense despite the perceived
inconsistency, but it's definitely worth documenting properly. It also already
covers the usecase for munlockall2(MCL_FUTURE) which IIRC you had in the earlier
revisions...
prev parent reply other threads:[~2015-07-29 10:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 21:28 [PATCH V5 0/7] Allow user to request memory to be locked on page fault Eric B Munson
2015-07-24 21:28 ` [PATCH V5 2/7] mm: mlock: Add new mlock system call Eric B Munson
2015-07-27 6:43 ` Kirill A. Shutemov
2015-07-24 21:28 ` [PATCH V5 4/7] mm: mlock: Add mlock flags to enable VM_LOCKONFAULT usage Eric B Munson
2015-07-27 7:15 ` Kirill A. Shutemov
2015-07-24 21:28 ` [PATCH V5 5/7] mm: mmap: Add mmap flag to request VM_LOCKONFAULT Eric B Munson
2015-07-27 7:31 ` Kirill A. Shutemov
2015-07-27 13:41 ` Eric B Munson
2015-07-27 14:03 ` Kirill A. Shutemov
2015-07-27 14:11 ` Eric B Munson
2015-07-27 9:08 ` [PATCH V5 0/7] Allow user to request memory to be locked on page fault Vlastimil Babka
2015-07-27 13:35 ` Eric B Munson
2015-07-27 14:16 ` Vlastimil Babka
2015-07-27 14:54 ` Eric B Munson
2015-07-27 15:40 ` Vlastimil Babka
2015-07-28 11:17 ` Michal Hocko
2015-07-28 11:23 ` Vlastimil Babka
2015-07-28 13:49 ` Eric B Munson
2015-07-28 15:10 ` Vlastimil Babka
2015-07-28 18:06 ` Eric B Munson
2015-07-29 10:45 ` Michal Hocko
2015-07-29 10:49 ` Vlastimil Babka [this message]
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=55B8AFD5.3030902@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=emunson@akamai.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=ralf@linux-mips.org \
--cc=shuahkh@osg.samsung.com \
--cc=sparclinux@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).