From: Martin Oliveira <martin.oliveira@eideticom.com>
To: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.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>,
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>,
Martin Oliveira <martin.oliveira@eideticom.com>
Subject: [PATCH v5 0/4] Enable P2PDMA in Userspace RDMA
Date: Thu, 8 Aug 2024 12:33:36 -0600 [thread overview]
Message-ID: <20240808183340.483468-1-martin.oliveira@eideticom.com> (raw)
In the last version of this series, there was a discrepancy on how
->close() and ->page_mkwrite() were handled, as just the latter had a
WARN. Matthew requested that they be the same, so this version adds an
extra patch to add a WARN to the ->close() handling. Everything else
remains the same.
On a different note, I was wondering which tree should take this series.
Thanks to everyone who has provided feedback!
Thanks,
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 v5:
- Add a WARN in the ->close() handling (per Matthew)
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 (4):
kernfs: upgrade ->close check on mmap to WARN
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(-)
--
2.43.0
next reply other threads:[~2024-08-08 18:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-08 18:33 Martin Oliveira [this message]
2024-08-08 18:33 ` [PATCH v5 1/4] kernfs: add a WARN_ON_ONCE if ->close is set Martin Oliveira
2024-08-09 5:37 ` Greg Kroah-Hartman
2024-08-09 15:41 ` Martin Oliveira
2024-08-11 8:31 ` Greg Kroah-Hartman
2024-08-12 6:38 ` Christoph Hellwig
2024-08-12 6:38 ` Christoph Hellwig
2024-08-08 18:33 ` [PATCH v5 2/4] kernfs: remove page_mkwrite() from vm_operations_struct Martin Oliveira
2024-08-12 6:38 ` Christoph Hellwig
2024-08-08 18:33 ` [PATCH v5 3/4] mm/gup: allow FOLL_LONGTERM & FOLL_PCI_P2PDMA Martin Oliveira
2024-08-12 6:39 ` Christoph Hellwig
2024-08-12 23:12 ` Jason Gunthorpe
2024-08-13 5:41 ` Christoph Hellwig
2024-08-13 16:05 ` Jason Gunthorpe
2024-08-13 17:03 ` Dan Williams
2024-08-14 0:02 ` Jason Gunthorpe
2024-08-14 4:26 ` Christoph Hellwig
2024-08-15 16:38 ` Jason Gunthorpe
2024-08-08 18:33 ` [PATCH v5 4/4] 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=20240808183340.483468-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