Patch "mm: introduce get_user_pages_longterm" has been added to the 4.14-stable tree

This is a note to let you know that I've just added the patch titled

mm: introduce get_user_pages_longterm

to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
mm-introduce-get_user_pages_longterm.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Dan Williams <[email protected]>
Date: Wed, 29 Nov 2017 16:10:35 -0800
Subject: mm: introduce get_user_pages_longterm

From: Dan Williams <[email protected]>

commit 2bb6d2837083de722bfdc369cb0d76ce188dd9b4 upstream.

Patch series "introduce get_user_pages_longterm()", v2.

Here is a new get_user_pages api for cases where a driver intends to keep an elevated page count indefinitely. This is distinct from usages like iov_iter_get_pages where the elevated page counts are transient. The iov_iter_get_pages cases immediately turn around and submit the pages to a device driver which will put_page when the i/o operation completes (under kernel control).

In the longterm case userspace is responsible for dropping the page reference at some undefined point in the future. This is untenable for filesystem-dax case where the filesystem is in control of the lifetime of the block / page and needs reasonable limits on how long it can wait for pages in a mapping to become idle.

Fixing filesystems to actually wait for dax pages to be idle before blocks from a truncate/hole-punch operation are repurposed is saved for a later patch series.

Also, allowing longterm registration of dax mappings is a future patch series that introduces a "map with lease" semantic where the kernel can revoke a lease and force userspace to drop its page references.

I have also tagged these for -stable to purposely break cases that might assume that longterm memory registrations for filesystem-dax mappings were supported by the kernel. The behavior regression this policy change implies is one of the reasons we maintain the "dax enabled.
Warning: EXPERIMENTAL, use at your own risk" notification when mounting a filesystem in dax mode.

It is worth noting the device-dax interface does not suffer the same constraints since it does not support file space management operations like hole-punch.

This patch (of 4):

Until there is a solution to the dma-to-dax vs truncate problem it is not safe to allow long standing memory registrations against filesytem-dax vmas. Device-dax vmas do not have this problem and are explicitly allowed.

This is temporary until a "memory registration with layout-lease" mechanism can be implemented for the affected sub-systems (RDMA and V4L2).

---
 include/linux/fs.h |   14 +++++++++++
 include/linux/mm.h |   13 ++++++++++
 mm/gup.c           |   64 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 91 insertions(+)

@@ -3175,6 +3175,20 @@ static inline bool vma_is_dax(struct vm_
 	return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
 }
 
+static inline bool vma_is_fsdax(struct vm_area_struct *vma)
+{
+	struct inode *inode;
+
+	if (!vma->vm_file)
+		return false;
+	if (!vma_is_dax(vma))
+		return false;
+	inode = file_inode(vma->vm_file);
+	if (inode->i_mode == S_IFCHR)
+		return false; /* device-dax */
+	return true;
+}
+
 static inline int iocb_flags(struct file *file)
 {
 	int res = 0;

@@ -1368,6 +1368,19 @@ long get_user_pages_locked(unsigned long
 		    unsigned int gup_flags, struct page **pages, int *locked);
 long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
 		    struct page **pages, unsigned int gup_flags);
+#ifdef CONFIG_FS_DAX
+long get_user_pages_longterm(unsigned long start, unsigned long nr_pages,
+			    unsigned int gup_flags, struct page **pages,
+			    struct vm_area_struct **vmas);
+#else
+static inline long get_user_pages_longterm(unsigned long start,
+		unsigned long nr_pages, unsigned int gup_flags,
+		struct page **pages, struct vm_area_struct **vmas)
+{
+	return get_user_pages(start, nr_pages, gup_flags, pages, vmas);
+}
+#endif /* CONFIG_FS_DAX */
+
 int get_user_pages_fast(unsigned long start, int nr_pages, int write,
 			struct page **pages);
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.14/mm-hugetlbfs-introduce-split-to-vm_operations_struct.patch queue-4.14/ib-core-disable-memory-registration-of-filesystem-dax-vmas.patch queue-4.14/mm-introduce-get_user_pages_longterm.patch queue-4.14/mm-fail-get_vaddr_frames-for-filesystem-dax-mappings.patch queue-4.14/device-dax-implement-split-to-catch-invalid-munmap-attempts.patch queue-4.14/v4l2-disable-filesystem-dax-mapping-support.patch queue-4.14/mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages.patch queue-4.14/mm-madvise.c-fix-madvise-infinite-loop-under-special-circumstances.patch