* [PATCH v2 1/3] For Ira: tiny formatting tweak to kerneldoc
2019-08-21 4:07 [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN John Hubbard
@ 2019-08-21 4:07 ` John Hubbard
2019-08-21 4:07 ` [PATCH v2 2/3] mm/gup: introduce FOLL_PIN flag for get_user_pages() John Hubbard
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: John Hubbard @ 2019-08-21 4:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, Dan Williams, Dave Chinner, Ira Weiny,
Jan Kara, Jason Gunthorpe, Jérôme Glisse,
Vlastimil Babka, LKML, linux-mm, linux-fsdevel, linux-rdma,
John Hubbard
For your vaddr_pin_pages() and vaddr_unpin_pages().
Just merge it into wherever it goes please. Didn't want to
cause merge problems so it's a separate patch-let.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
mm/gup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 56421b880325..e49096d012ea 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2465,7 +2465,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
EXPORT_SYMBOL_GPL(get_user_pages_fast);
/**
- * vaddr_pin_pages pin pages by virtual address and return the pages to the
+ * vaddr_pin_pages() - pin pages by virtual address and return the pages to the
* user.
*
* @addr: start address
@@ -2505,7 +2505,7 @@ long vaddr_pin_pages(unsigned long addr, unsigned long nr_pages,
EXPORT_SYMBOL(vaddr_pin_pages);
/**
- * vaddr_unpin_pages - counterpart to vaddr_pin_pages
+ * vaddr_unpin_pages() - counterpart to vaddr_pin_pages
*
* @pages: array of pages returned
* @nr_pages: number of pages in pages
--
2.22.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH v2 2/3] mm/gup: introduce FOLL_PIN flag for get_user_pages()
2019-08-21 4:07 [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN John Hubbard
2019-08-21 4:07 ` [PATCH v2 1/3] For Ira: tiny formatting tweak to kerneldoc John Hubbard
@ 2019-08-21 4:07 ` John Hubbard
2019-08-21 4:07 ` [PATCH v2 3/3] mm/gup: introduce vaddr_pin_pages_remote(), and invoke it John Hubbard
2019-08-23 0:24 ` [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN Ira Weiny
3 siblings, 0 replies; 6+ messages in thread
From: John Hubbard @ 2019-08-21 4:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, Dan Williams, Dave Chinner, Ira Weiny,
Jan Kara, Jason Gunthorpe, Jérôme Glisse,
Vlastimil Babka, LKML, linux-mm, linux-fsdevel, linux-rdma,
John Hubbard, Michal Hocko
As explained in the newly added documentation for FOLL_PIN and
FOLL_LONGTERM, in every case where vaddr_pin_pages() is required,
FOLL_PIN must be set. That reason, plus a desire to keep FOLL_PIN
an internal (to get_user_pages() and follow_page()) detail, is why
vaddr_pin_pages() sets FOLL_PIN.
FOLL_LONGTERM, on the other hand, in only set in *some* cases, but
not all. For that reason, this patch moves the setting of FOLL_LONGTERM
out to the caller.
Also add fairly extensive documentation of the meaning and use
of both FOLL_PIN and FOLL_LONGTERM.
Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
in this documentation. (I've reworded it and expanded on it slightly.)
The motivation behind moving away from "bare" get_user_pages() calls
is described in more detail in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.cz>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
drivers/infiniband/core/umem.c | 1 +
include/linux/mm.h | 56 ++++++++++++++++++++++++++++++----
mm/gup.c | 2 +-
3 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index e69eecb0023f..d84f1bfb8d21 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -300,6 +300,7 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, unsigned long addr,
while (npages) {
down_read(&mm->mmap_sem);
+ gup_flags |= FOLL_LONGTERM;
ret = vaddr_pin_pages(cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof (struct page *)),
diff --git a/include/linux/mm.h b/include/linux/mm.h
index bc675e94ddf8..6e7de424bf5e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2644,6 +2644,8 @@ static inline vm_fault_t vmf_error(int err)
struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
unsigned int foll_flags);
+/* Flags for follow_page(), get_user_pages ("GUP"), and vaddr_pin_pages(): */
+
#define FOLL_WRITE 0x01 /* check pte is writable */
#define FOLL_TOUCH 0x02 /* mark page accessed */
#define FOLL_GET 0x04 /* do get_page on page */
@@ -2663,13 +2665,15 @@ 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:
+ * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
+ * other. Here is what they mean, and how to use them:
*
* FOLL_LONGTERM indicates that the page will be held for an indefinite time
- * period _often_ under userspace control. This is contrasted with
- * iov_iter_get_pages() where usages which are transient.
+ * period _often_ under userspace control. This is in contrast to
+ * iov_iter_get_pages(), where usages which are transient.
*
* FIXME: For pages which are part of a filesystem, mappings are subject to the
* lifetime enforced by the filesystem and we need guarantees that longterm
@@ -2684,11 +2688,51 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
* Currently only get_user_pages() and get_user_pages_fast() support this flag
* and calls to get_user_pages_[un]locked are specifically not allowed. This
* is due to an incompatibility with the FS DAX check and
- * FAULT_FLAG_ALLOW_RETRY
+ * FAULT_FLAG_ALLOW_RETRY.
*
- * In the CMA case: longterm pins in a CMA region would unnecessarily fragment
- * that region. And so CMA attempts to migrate the page before pinning when
+ * In the CMA case: long term pins in a CMA region would unnecessarily fragment
+ * that region. And so, CMA attempts to migrate the page before pinning, when
* FOLL_LONGTERM is specified.
+ *
+ * FOLL_PIN indicates that a special kind of tracking (not just page->_refcount,
+ * but an additional pin counting system) will be invoked. This is intended for
+ * anything that gets a page reference and then touches page data (for example,
+ * Direct IO). This lets the filesystem know that some non-file-system entity is
+ * potentially changing the pages' data. FOLL_PIN pages must be released,
+ * ultimately, by a call to put_user_page(). Typically that will be via one of
+ * the vaddr_unpin_pages() variants.
+ *
+ * FIXME: note that this special tracking is not in place yet. However, the
+ * pages should still be released by put_user_page().
+ *
+ * When and where to use each flag:
+ *
+ * CASE 1: Direct IO (DIO). There are GUP references to pages that are serving
+ * as DIO buffers. These buffers are needed for a relatively short time (so they
+ * are not "long term"). No special synchronization with page_mkclean() or
+ * munmap() is provided. Therefore, flags to set at the call site are:
+ *
+ * FOLL_PIN
+ *
+ * CASE 2: RDMA. There are GUP references to pages that are serving as DMA
+ * buffers. These buffers are needed for a long time ("long term"). No special
+ * synchronization with page_mkclean() or munmap() is provided. Therefore, flags
+ * to set at the call site are:
+ *
+ * FOLL_PIN | FOLL_LONGTERM
+ *
+ * There is also a special case when the pages are DAX pages: in addition to the
+ * above flags, the caller needs a file lease. This is provided via the struct
+ * vaddr_pin argument to vaddr_pin_pages().
+ *
+ * CASE 3: ODP (Mellanox/Infiniband On Demand Paging: the hardware supports
+ * replayable page faulting). There are GUP references to pages serving as DMA
+ * buffers. For ODP, MMU notifiers are used to synchronize with page_mkclean()
+ * and munmap(). Therefore, normal GUP calls are sufficient, so neither flag
+ * needs to be set.
+ *
+ * CASE 4: pinning for struct page manipulation only. Here, normal GUP calls are
+ * sufficient, so neither flag needs to be set.
*/
static inline int vm_fault_to_errno(vm_fault_t vm_fault, int foll_flags)
diff --git a/mm/gup.c b/mm/gup.c
index e49096d012ea..ba316d960d7a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2490,7 +2490,7 @@ long vaddr_pin_pages(unsigned long addr, unsigned long nr_pages,
{
long ret;
- gup_flags |= FOLL_LONGTERM;
+ gup_flags |= FOLL_PIN;
if (!vaddr_pin || (!vaddr_pin->mm && !vaddr_pin->f_owner))
return -EINVAL;
--
2.22.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH v2 3/3] mm/gup: introduce vaddr_pin_pages_remote(), and invoke it
2019-08-21 4:07 [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN John Hubbard
2019-08-21 4:07 ` [PATCH v2 1/3] For Ira: tiny formatting tweak to kerneldoc John Hubbard
2019-08-21 4:07 ` [PATCH v2 2/3] mm/gup: introduce FOLL_PIN flag for get_user_pages() John Hubbard
@ 2019-08-21 4:07 ` John Hubbard
2019-08-23 0:24 ` [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN Ira Weiny
3 siblings, 0 replies; 6+ messages in thread
From: John Hubbard @ 2019-08-21 4:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, Dan Williams, Dave Chinner, Ira Weiny,
Jan Kara, Jason Gunthorpe, Jérôme Glisse,
Vlastimil Babka, LKML, linux-mm, linux-fsdevel, linux-rdma,
John Hubbard
vaddr_pin_user_pages_remote() is the "vaddr_pin_pages" corresponding
variant to get_user_pages_remote(), except that:
a) it sets FOLL_PIN, and
b) it can handle FOLL_LONGTERM (and the associated vaddr_pin arg).
Change process_vm_rw_single_vec() to invoke the new function.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Cc: Ira Weiny <ira.weiny@intel.com>
---
include/linux/mm.h | 5 +++++
mm/gup.c | 34 ++++++++++++++++++++++++++++++++++
mm/process_vm_access.c | 23 +++++++++++++----------
3 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 6e7de424bf5e..849b509e9f89 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1606,6 +1606,11 @@ int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
long vaddr_pin_pages(unsigned long addr, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vaddr_pin *vaddr_pin);
+long vaddr_pin_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas, int *locked,
+ struct vaddr_pin *vaddr_pin);
void vaddr_unpin_pages(struct page **pages, unsigned long nr_pages,
struct vaddr_pin *vaddr_pin, bool make_dirty);
bool mapping_inode_has_layout(struct vaddr_pin *vaddr_pin, struct page *page);
diff --git a/mm/gup.c b/mm/gup.c
index ba316d960d7a..d713ed9d4b9a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2522,3 +2522,37 @@ void vaddr_unpin_pages(struct page **pages, unsigned long nr_pages,
__put_user_pages_dirty_lock(pages, nr_pages, make_dirty, vaddr_pin);
}
EXPORT_SYMBOL(vaddr_unpin_pages);
+
+/**
+ * vaddr_pin_user_pages_remote() - pin pages by virtual address and return the
+ * pages to the user.
+ *
+ * @tsk: the task_struct to use for page fault accounting, or
+ * NULL if faults are not to be recorded.
+ * @mm: mm_struct of target mm
+ * @addr: start address
+ * @nr_pages: number of pages to pin
+ * @gup_flags: flags to use for the pin. Please see FOLL_* documentation in
+ * mm.h.
+ * @pages: array of pages returned
+ * @vaddr_pin: If FOLL_LONGTERM is set, then vaddr_pin should point to an
+ * initialized struct that contains the owning mm and file. Otherwise, vaddr_pin
+ * should be set to NULL.
+ *
+ * This is the "vaddr_pin_pages" corresponding variant to
+ * get_user_pages_remote(), except that:
+ * a) it sets FOLL_PIN, and
+ * b) it can handle FOLL_LONGTERM (and the associated vaddr_pin arg).
+ */
+long vaddr_pin_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas, int *locked,
+ struct vaddr_pin *vaddr_pin)
+{
+ gup_flags |= FOLL_TOUCH | FOLL_REMOTE | FOLL_PIN;
+
+ return __get_user_pages_locked(tsk, mm, start, nr_pages, pages, vmas,
+ locked, gup_flags, vaddr_pin);
+}
+EXPORT_SYMBOL(vaddr_pin_user_pages_remote);
diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
index 357aa7bef6c0..28e0a17b6080 100644
--- a/mm/process_vm_access.c
+++ b/mm/process_vm_access.c
@@ -44,7 +44,6 @@ static int process_vm_rw_pages(struct page **pages,
if (vm_write) {
copied = copy_page_from_iter(page, offset, copy, iter);
- set_page_dirty_lock(page);
} else {
copied = copy_page_to_iter(page, offset, copy, iter);
}
@@ -96,7 +95,7 @@ static int process_vm_rw_single_vec(unsigned long addr,
flags |= FOLL_WRITE;
while (!rc && nr_pages && iov_iter_count(iter)) {
- int pages = min(nr_pages, max_pages_per_loop);
+ int pinned_pages = min(nr_pages, max_pages_per_loop);
int locked = 1;
size_t bytes;
@@ -106,14 +105,17 @@ static int process_vm_rw_single_vec(unsigned long addr,
* current/current->mm
*/
down_read(&mm->mmap_sem);
- pages = get_user_pages_remote(task, mm, pa, pages, flags,
- process_pages, NULL, &locked);
+
+ pinned_pages = vaddr_pin_user_pages_remote(task, mm, pa,
+ pinned_pages, flags,
+ process_pages, NULL,
+ &locked, NULL);
if (locked)
up_read(&mm->mmap_sem);
- if (pages <= 0)
+ if (pinned_pages <= 0)
return -EFAULT;
- bytes = pages * PAGE_SIZE - start_offset;
+ bytes = pinned_pages * PAGE_SIZE - start_offset;
if (bytes > len)
bytes = len;
@@ -122,10 +124,11 @@ static int process_vm_rw_single_vec(unsigned long addr,
vm_write);
len -= bytes;
start_offset = 0;
- nr_pages -= pages;
- pa += pages * PAGE_SIZE;
- while (pages)
- put_page(process_pages[--pages]);
+ nr_pages -= pinned_pages;
+ pa += pinned_pages * PAGE_SIZE;
+
+ /* If vm_write is set, the pages need to be made dirty: */
+ vaddr_unpin_pages(process_pages, pinned_pages, NULL, vm_write);
}
return rc;
--
2.22.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN
2019-08-21 4:07 [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN John Hubbard
` (2 preceding siblings ...)
2019-08-21 4:07 ` [PATCH v2 3/3] mm/gup: introduce vaddr_pin_pages_remote(), and invoke it John Hubbard
@ 2019-08-23 0:24 ` Ira Weiny
2019-08-23 0:36 ` John Hubbard
3 siblings, 1 reply; 6+ messages in thread
From: Ira Weiny @ 2019-08-23 0:24 UTC (permalink / raw)
To: John Hubbard
Cc: Andrew Morton, Christoph Hellwig, Dan Williams, Dave Chinner,
Jan Kara, Jason Gunthorpe, Jérôme Glisse,
Vlastimil Babka, LKML, linux-mm, linux-fsdevel, linux-rdma
On Tue, Aug 20, 2019 at 09:07:24PM -0700, John Hubbard wrote:
> Hi Ira,
>
> This is for your tree. I'm dropping the RFC because this aspect is
> starting to firm up pretty well.
>
> I've moved FOLL_PIN inside the vaddr_pin_*() routines, and moved
> FOLL_LONGTERM outside, based on our recent discussions. This is
> documented pretty well within the patches.
>
> Note that there are a lot of references in comments and commit
> logs, to vaddr_pin_pages(). We'll want to catch all of those if
> we rename that. I am pushing pretty hard to rename it to
> vaddr_pin_user_pages().
>
> v1 of this may be found here:
> https://lore.kernel.org/r/20190812015044.26176-1-jhubbard@nvidia.com
I am really sorry about this...
I think it is fine to pull these in... There are some nits which are wrong but
I think with the XDP complication and Daves' objection I think the vaddr_pin
information is going to need reworking. So the documentation there is probably
wrong. But until we know what it is going to be we should just take this.
Do you have a branch with this on it?
The patches don't seem to apply. Looks like they got corrupted somewhere...
:-/
Thanks,
Ira
>
> John Hubbard (3):
> For Ira: tiny formatting tweak to kerneldoc
> mm/gup: introduce FOLL_PIN flag for get_user_pages()
> mm/gup: introduce vaddr_pin_pages_remote(), and invoke it
>
> drivers/infiniband/core/umem.c | 1 +
> include/linux/mm.h | 61 ++++++++++++++++++++++++++++++----
> mm/gup.c | 40 ++++++++++++++++++++--
> mm/process_vm_access.c | 23 +++++++------
> 4 files changed, 106 insertions(+), 19 deletions(-)
>
> --
> 2.22.1
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN
2019-08-23 0:24 ` [PATCH v2 0/3] mm/gup: introduce vaddr_pin_pages_remote(), FOLL_PIN Ira Weiny
@ 2019-08-23 0:36 ` John Hubbard
0 siblings, 0 replies; 6+ messages in thread
From: John Hubbard @ 2019-08-23 0:36 UTC (permalink / raw)
To: Ira Weiny
Cc: Andrew Morton, Christoph Hellwig, Dan Williams, Dave Chinner,
Jan Kara, Jason Gunthorpe, Jérôme Glisse,
Vlastimil Babka, LKML, linux-mm, linux-fsdevel, linux-rdma
On 8/22/19 5:24 PM, Ira Weiny wrote:
> On Tue, Aug 20, 2019 at 09:07:24PM -0700, John Hubbard wrote:
>> Hi Ira,
>>
>> This is for your tree. I'm dropping the RFC because this aspect is
>> starting to firm up pretty well.
>>
>> I've moved FOLL_PIN inside the vaddr_pin_*() routines, and moved
>> FOLL_LONGTERM outside, based on our recent discussions. This is
>> documented pretty well within the patches.
>>
>> Note that there are a lot of references in comments and commit
>> logs, to vaddr_pin_pages(). We'll want to catch all of those if
>> we rename that. I am pushing pretty hard to rename it to
>> vaddr_pin_user_pages().
>>
>> v1 of this may be found here:
>> https://lore.kernel.org/r/20190812015044.26176-1-jhubbard@nvidia.com
>
> I am really sorry about this...
>
> I think it is fine to pull these in... There are some nits which are wrong but
> I think with the XDP complication and Daves' objection I think the vaddr_pin
> information is going to need reworking. So the documentation there is probably
> wrong. But until we know what it is going to be we should just take this.
>
Sure, I was thinking the same thing: FOLL_PIN is clearing up, but vaddr_pin_pages()
is still under heavy discussion.
> Do you have a branch with this on it?
>
Yes, it's on: git@github.com:johnhubbard/linux.git , branch: vaddr_FOLL_PIN_next
> The patches don't seem to apply. Looks like they got corrupted somewhere...
>
Lately I'm trying out .nvidia.com outgoing servers for git-send-email, so I'm
still nervous about potential email-based patch problems. I suspect, though,
that it's really just a "must be on exactly the right commit in order to apply"
situation. Please let me know, so I can make any corrections necessary on this end.
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply [flat|nested] 6+ messages in thread