From: john.hubbard@gmail.com
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Christoph Hellwig" <hch@infradead.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"Dave Chinner" <david@fromorbit.com>,
"Ira Weiny" <ira.weiny@intel.com>, "Jan Kara" <jack@suse.cz>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Jérôme Glisse" <jglisse@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-rdma@vger.kernel.org, "John Hubbard" <jhubbard@nvidia.com>,
"Michal Hocko" <mhocko@kernel.org>
Subject: [RFC PATCH 1/2] mm/gup: introduce FOLL_PIN flag for get_user_pages()
Date: Sun, 11 Aug 2019 18:50:43 -0700 [thread overview]
Message-ID: <20190812015044.26176-2-jhubbard@nvidia.com> (raw)
In-Reply-To: <20190812015044.26176-1-jhubbard@nvidia.com>
From: John Hubbard <jhubbard@nvidia.com>
FOLL_PIN is set by vaddr_pin_pages(). This is different than
FOLL_LONGTERM, because even short term page pins need a new kind
of tracking, if those pinned pages' data is going to potentially
be modified.
This situation is described in more detail in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
FOLL_PIN is added now, rather than waiting until there is code that
takes action based on FOLL_PIN. That's because having FOLL_PIN in
the code helps to highlight the differences between:
a) get_user_pages(): soon to be deprecated. Used to pin pages,
but without awareness of file systems that might use those
pages,
b) The original vaddr_pin_pages(): intended only for
FOLL_LONGTERM and DAX use cases. This assumes direct IO
and therefore is not applicable the most of the other
callers of get_user_pages(), and
c) The new vaddr_pin_pages(), which provides the correct
get_user_pages() flags for all cases, by setting FOLL_PIN.
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
include/linux/mm.h | 1 +
mm/gup.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 90c5802866df..61b616cd9243 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2663,6 +2663,7 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
#define FOLL_ANON 0x8000 /* don't do file mappings */
#define FOLL_LONGTERM 0x10000 /* mapping lifetime is indefinite: see below */
#define FOLL_SPLIT_PMD 0x20000 /* split huge pmd before returning */
+#define FOLL_PIN 0x40000 /* pages must be released via put_user_page() */
/*
* NOTE on FOLL_LONGTERM:
diff --git a/mm/gup.c b/mm/gup.c
index 58f008a3c153..85f09958fbdc 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2494,6 +2494,9 @@ EXPORT_SYMBOL_GPL(get_user_pages_fast);
* being made against. Usually "current->mm".
*
* Expects mmap_sem to be read locked.
+ *
+ * Implementation note: this sets FOLL_PIN, which means that the pages must
+ * ultimately be released by put_user_page().
*/
long vaddr_pin_pages(unsigned long addr, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
@@ -2501,7 +2504,7 @@ long vaddr_pin_pages(unsigned long addr, unsigned long nr_pages,
{
long ret;
- gup_flags |= FOLL_LONGTERM;
+ gup_flags |= FOLL_LONGTERM | FOLL_PIN;
if (!vaddr_pin || (!vaddr_pin->mm && !vaddr_pin->f_owner))
return -EINVAL;
--
2.22.0
next prev parent reply other threads:[~2019-08-12 1:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-12 1:50 [RFC PATCH 0/2] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN john.hubbard
2019-08-12 1:50 ` john.hubbard [this message]
2019-08-12 1:50 ` [RFC PATCH 2/2] mm/gup: introduce vaddr_pin_pages_remote() john.hubbard
2019-08-12 22:03 ` Ira Weiny
2019-08-12 22:21 ` John Hubbard
2019-08-12 23:49 ` Ira Weiny
2019-08-13 0:07 ` John Hubbard
2019-08-13 21:08 ` Ira Weiny
2019-08-14 0:51 ` John Hubbard
2019-08-14 0:56 ` John Hubbard
2019-08-14 23:50 ` Ira Weiny
2019-08-15 0:02 ` John Hubbard
2019-08-15 3:01 ` John Hubbard
2019-08-15 13:26 ` Jan Kara
2019-08-15 13:35 ` Jan Kara
2019-08-15 14:51 ` Jason Gunthorpe
2019-08-15 17:32 ` Ira Weiny
2019-08-15 17:41 ` John Hubbard
2019-08-16 2:14 ` John Hubbard
2019-08-16 15:41 ` Jan Kara
2019-08-16 18:33 ` Ira Weiny
2019-08-16 18:50 ` John Hubbard
2019-08-16 21:59 ` Ira Weiny
2019-08-16 22:36 ` John Hubbard
2019-08-16 8:47 ` Vlastimil Babka
2019-08-16 15:44 ` Jan Kara
2019-08-16 15:52 ` Jerome Glisse
2019-08-16 16:13 ` Jan Kara
2019-08-16 16:31 ` Jason Gunthorpe
2019-08-16 16:54 ` Jerome Glisse
2019-08-16 17:04 ` Jason Gunthorpe
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=20190812015044.26176-2-jhubbard@nvidia.com \
--to=john.hubbard@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mhocko@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).