From: Dan Williams <dan.j.williams@intel.com> To: akpm@linux-foundation.org Cc: Sean Hefty <sean.hefty@intel.com>, Jan Kara <jack@suse.cz>, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Doug Ledford <dledford@redhat.com>, stable@vger.kernel.org, Hal Rosenstock <hal.rosenstock@gmail.com>, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>, linux-mm@kvack.org, Jeff Moyer <jmoyer@redhat.com>, Ross Zwisler <ross.zwisler@linux.intel.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Christoph Hellwig <hch@lst.de>, linux-media@vger.kernel.org Subject: [PATCH 0/3] introduce get_user_pages_longterm() Date: Mon, 06 Nov 2017 16:57:10 -0800 [thread overview] Message-ID: <151001623063.16354.14661493921524115663.stgit@dwillia2-desk3.amr.corp.intel.com> (raw) Andrew, 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. --- Dan Williams (3): mm: introduce get_user_pages_longterm IB/core: disable memory registration of fileystem-dax vmas [media] v4l2: disable filesystem-dax mapping support drivers/infiniband/core/umem.c | 2 - drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +- include/linux/mm.h | 3 + mm/gup.c | 75 +++++++++++++++++++++++++++++ 4 files changed, 82 insertions(+), 3 deletions(-) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com> To: akpm@linux-foundation.org Cc: Sean Hefty <sean.hefty@intel.com>, Jan Kara <jack@suse.cz>, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Doug Ledford <dledford@redhat.com>, stable@vger.kernel.org, Hal Rosenstock <hal.rosenstock@gmail.com>, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>, linux-mm@kvack.org, Jeff Moyer <jmoyer@redhat.com>, Ross Zwisler <ross.zwisler@linux.intel.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Christoph Hellwig <hch@lst.de>, linux-media@vger.kernel.org Subject: [PATCH 0/3] introduce get_user_pages_longterm() Date: Mon, 06 Nov 2017 16:57:10 -0800 [thread overview] Message-ID: <151001623063.16354.14661493921524115663.stgit@dwillia2-desk3.amr.corp.intel.com> (raw) Andrew, 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. --- Dan Williams (3): mm: introduce get_user_pages_longterm IB/core: disable memory registration of fileystem-dax vmas [media] v4l2: disable filesystem-dax mapping support drivers/infiniband/core/umem.c | 2 - drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +- include/linux/mm.h | 3 + mm/gup.c | 75 +++++++++++++++++++++++++++++ 4 files changed, 82 insertions(+), 3 deletions(-)
next reply other threads:[~2017-11-07 0:57 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-07 0:57 Dan Williams [this message] 2017-11-07 0:57 ` [PATCH 0/3] introduce get_user_pages_longterm() Dan Williams 2017-11-07 0:57 ` [PATCH 1/3] mm: introduce get_user_pages_longterm Dan Williams 2017-11-07 0:57 ` Dan Williams 2017-11-10 9:01 ` Christoph Hellwig 2017-11-10 9:01 ` Christoph Hellwig 2017-11-07 0:57 ` [PATCH 2/3] IB/core: disable memory registration of fileystem-dax vmas Dan Williams 2017-11-07 0:57 ` Dan Williams [not found] ` <151001624138.16354.16836728315400060928.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2017-11-10 9:01 ` Christoph Hellwig 2017-11-10 9:01 ` Christoph Hellwig 2017-11-10 9:01 ` Christoph Hellwig 2017-11-07 0:57 ` [PATCH 3/3] [media] v4l2: disable filesystem-dax mapping support Dan Williams 2017-11-07 0:57 ` Dan Williams 2017-11-07 8:33 ` Mauro Carvalho Chehab 2017-11-07 8:33 ` Mauro Carvalho Chehab 2017-11-07 17:43 ` Dan Williams 2017-11-07 17:43 ` Dan Williams 2017-11-07 20:39 ` Mauro Carvalho Chehab 2017-11-07 20:39 ` Mauro Carvalho Chehab 2017-11-08 0:13 ` Dan Williams 2017-11-08 0:13 ` Dan Williams
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=151001623063.16354.14661493921524115663.stgit@dwillia2-desk3.amr.corp.intel.com \ --to=dan.j.williams@intel.com \ --cc=akpm@linux-foundation.org \ --cc=dledford@redhat.com \ --cc=hal.rosenstock@gmail.com \ --cc=hch@lst.de \ --cc=jack@suse.cz \ --cc=jgunthorpe@obsidianresearch.com \ --cc=jmoyer@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-rdma@vger.kernel.org \ --cc=mchehab@kernel.org \ --cc=ross.zwisler@linux.intel.com \ --cc=sean.hefty@intel.com \ --cc=stable@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.