All of lore.kernel.org
 help / color / mirror / Atom feed
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(-)

             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: link
Be 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.