From: Martin Oliveira <martin.oliveira@eideticom.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-rdma@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Artemy Kovalyov <artemyko@nvidia.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
Logan Gunthorpe <logang@deltatee.com>,
Martin Oliveira <martin.oliveira@eideticom.com>,
Michael Guralnik <michaelgur@nvidia.com>,
Mike Marciniszyn <mike.marciniszyn@intel.com>,
Shiraz Saleem <shiraz.saleem@intel.com>,
Tejun Heo <tj@kernel.org>, John Hubbard <jhubbard@nvidia.com>,
Dan Williams <dan.j.williams@intel.com>,
David Sloan <david.sloan@eideticom.com>
Subject: [PATCH v4 0/3] Enable P2PDMA in Userspace RDMA
Date: Mon, 8 Jul 2024 10:57:11 -0600 [thread overview]
Message-ID: <20240708165714.3401377-1-martin.oliveira@eideticom.com> (raw)
This version of this patch series fixes the unhandled WARN issue from
v3. Everything else remains the same. Thanks to everyone who provided
reviews and feedback!
Martin
Original cover letter:
This patch series enables P2PDMA memory to be used in userspace RDMA
transfers. With this series, P2PDMA memory mmaped into userspace (ie.
only NVMe CMBs, at the moment) can then be used with ibv_reg_mr() (or
similar) interfaces. This can be tested by passing a sysfs p2pmem
allocator to the --mmap flag of the perftest tools.
This requires addressing two issues:
* Stop exporting kernfs VMAs with page_mkwrite, which is incompatible
with FOLL_LONGTERM and is redudant since the default fault code has the
same behavior as kernfs_vma_page_mkwrite() (i.e., call
file_update_time()).
* Remove the restriction on FOLL_LONGTREM with FOLL_PCI_P2PDMA which was
initially put in place due to excessive caution with assuming P2PDMA
would have similar problems to fsdax with unmap_mapping_range(). Seeing
P2PDMA only uses unmap_mapping_range() on device unbind and immediately
waits for all page reference counts to go to zero after calling it, it
is actually believed to be safe from reuse and user access faults. See
[1] for more discussion.
This was tested using a Mellanox ConnectX-6 SmartNIC (MT28908 Family),
using the mlx5_core driver, as well as an NVMe CMB.
Thanks,
Martin
[1]: https://lore.kernel.org/linux-mm/87cypuvh2i.fsf@nvdebian.thelocal/T/
--
Changes in v4:
- Actually handle the WARN if someone sets ->page_mkwrite
Changes in v3:
- Change to WARN_ON() if an implementaion of kernfs sets
.page_mkwrite() (Suggested by Christoph)
- Removed fast-gup patch
Changes in v2:
- Remove page_mkwrite() for all kernfs, instead of creating a
different vm_ops for p2pdma.
Martin Oliveira (3):
kernfs: remove page_mkwrite() from vm_operations_struct
mm/gup: allow FOLL_LONGTERM & FOLL_PCI_P2PDMA
RDMA/umem: add support for P2P RDMA
drivers/infiniband/core/umem.c | 3 +++
fs/kernfs/file.c | 25 ++-----------------------
mm/gup.c | 5 -----
3 files changed, 5 insertions(+), 28 deletions(-)
base-commit: 22a40d14b572deb80c0648557f4bd502d7e83826
--
2.34.1
Martin Oliveira (3):
kernfs: remove page_mkwrite() from vm_operations_struct
mm/gup: allow FOLL_LONGTERM & FOLL_PCI_P2PDMA
RDMA/umem: add support for P2P RDMA
drivers/infiniband/core/umem.c | 3 +++
fs/kernfs/file.c | 40 ++++++++++------------------------
mm/gup.c | 5 -----
3 files changed, 14 insertions(+), 34 deletions(-)
base-commit: 256abd8e550ce977b728be79a74e1729438b4948
--
2.34.1
next reply other threads:[~2024-07-08 16:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 16:57 Martin Oliveira [this message]
2024-07-08 16:57 ` [PATCH v4 1/3] kernfs: remove page_mkwrite() from vm_operations_struct Martin Oliveira
2024-07-09 5:24 ` Greg Kroah-Hartman
2024-07-09 14:34 ` Matthew Wilcox
2024-07-08 16:57 ` [PATCH v4 2/3] mm/gup: allow FOLL_LONGTERM & FOLL_PCI_P2PDMA Martin Oliveira
2024-07-08 16:57 ` [PATCH v4 3/3] RDMA/umem: add support for P2P RDMA Martin Oliveira
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=20240708165714.3401377-1-martin.oliveira@eideticom.com \
--to=martin.oliveira@eideticom.com \
--cc=akpm@linux-foundation.org \
--cc=artemyko@nvidia.com \
--cc=dan.j.williams@intel.com \
--cc=david.sloan@eideticom.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=michaelgur@nvidia.com \
--cc=mike.marciniszyn@intel.com \
--cc=shiraz.saleem@intel.com \
--cc=tj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox