The patch titled Subject: mm: introduce get_user_pages_longterm has been added to the -mm tree. Its filename is mm-introduce-get_user_pages_longterm.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-introduce-get_user_pages_longterm.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-introduce-get_user_pages_longterm.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Dan Williams <dan.j.williams@xxxxxxxxx> Subject: mm: introduce get_user_pages_longterm 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). Link: http://lkml.kernel.org/r/151068939435.7446.13560129395419350737.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> Suggested-by: Christoph Hellwig <hch@xxxxxx> Cc: Doug Ledford <dledford@xxxxxxxxxx> Cc: Hal Rosenstock <hal.rosenstock@xxxxxxxxx> Cc: Inki Dae <inki.dae@xxxxxxxxxxx> Cc: Jan Kara <jack@xxxxxxx> Cc: Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> Cc: Jeff Moyer <jmoyer@xxxxxxxxxx> Cc: Joonyoung Shim <jy0922.shim@xxxxxxxxxxx> Cc: Kyungmin Park <kyungmin.park@xxxxxxxxxxx> Cc: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> Cc: Mel Gorman <mgorman@xxxxxxx> Cc: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> Cc: Sean Hefty <sean.hefty@xxxxxxxxx> Cc: Seung-Woo Kim <sw0312.kim@xxxxxxxxxxx> Cc: Vlastimil Babka <vbabka@xxxxxxx> Cc: <stable@xxxxxxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- include/linux/fs.h | 14 +++++++++ include/linux/mm.h | 13 ++++++++ mm/gup.c | 64 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 91 insertions(+) diff -puN include/linux/fs.h~mm-introduce-get_user_pages_longterm include/linux/fs.h --- a/include/linux/fs.h~mm-introduce-get_user_pages_longterm +++ a/include/linux/fs.h @@ -3194,6 +3194,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; diff -puN include/linux/mm.h~mm-introduce-get_user_pages_longterm include/linux/mm.h --- a/include/linux/mm.h~mm-introduce-get_user_pages_longterm +++ a/include/linux/mm.h @@ -1380,6 +1380,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); diff -puN mm/gup.c~mm-introduce-get_user_pages_longterm mm/gup.c --- a/mm/gup.c~mm-introduce-get_user_pages_longterm +++ a/mm/gup.c @@ -1095,6 +1095,70 @@ long get_user_pages(unsigned long start, } EXPORT_SYMBOL(get_user_pages); +#ifdef CONFIG_FS_DAX +/* + * This is the same as get_user_pages() in that it assumes we are + * operating on the current task's mm, but it goes further to validate + * that the vmas associated with the address range are suitable for + * longterm elevated page reference counts. For example, filesystem-dax + * mappings are subject to the lifetime enforced by the filesystem and + * we need guarantees that longterm users like RDMA and V4L2 only + * establish mappings that have a kernel enforced revocation mechanism. + * + * "longterm" == userspace controlled elevated page count lifetime. + * Contrast this to iov_iter_get_pages() usages which are transient. + */ +long get_user_pages_longterm(unsigned long start, unsigned long nr_pages, + unsigned int gup_flags, struct page **pages, + struct vm_area_struct **vmas_arg) +{ + struct vm_area_struct **vmas = vmas_arg; + struct vm_area_struct *vma_prev = NULL; + long rc, i; + + if (!pages) + return -EINVAL; + + if (!vmas) { + vmas = kzalloc(sizeof(struct vm_area_struct *) * nr_pages, + GFP_KERNEL); + if (!vmas) + return -ENOMEM; + } + + rc = get_user_pages(start, nr_pages, gup_flags, pages, vmas); + + for (i = 0; i < rc; i++) { + struct vm_area_struct *vma = vmas[i]; + + if (vma == vma_prev) + continue; + + vma_prev = vma; + + if (vma_is_fsdax(vma)) + break; + } + + /* + * Either get_user_pages() failed, or the vma validation + * succeeded, in either case we don't need to put_page() before + * returning. + */ + if (i >= rc) + goto out; + + for (i = 0; i < rc; i++) + put_page(pages[i]); + rc = -EOPNOTSUPP; +out: + if (vmas != vmas_arg) + kfree(vmas); + return rc; +} +EXPORT_SYMBOL(get_user_pages_longterm); +#endif /* CONFIG_FS_DAX */ + /** * populate_vma_page_range() - populate a range of pages in the vma. * @vma: target vma _ Patches currently in -mm which might be from dan.j.williams@xxxxxxxxx are mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages.patch mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages-v3.patch mm-switch-to-define-pmd_write-instead-of-__have_arch_pmd_write.patch mm-replace-pud_write-with-pud_access_permitted-in-fault-gup-paths.patch mm-replace-pud_write-with-pud_access_permitted-in-fault-gup-paths-v3.patch mm-replace-pmd_write-with-pmd_access_permitted-in-fault-gup-paths.patch mm-replace-pte_write-with-pte_access_permitted-in-fault-gup-paths.patch mm-hugetlbfs-introduce-split-to-vm_operations_struct.patch device-dax-implement-split-to-catch-invalid-munmap-attempts.patch mm-introduce-get_user_pages_longterm.patch mm-fail-get_vaddr_frames-for-filesystem-dax-mappings.patch v4l2-disable-filesystem-dax-mapping-support.patch ib-core-disable-memory-registration-of-fileystem-dax-vmas.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html