From: Logan Gunthorpe <logang@deltatee.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Martin Oliveira <Martin.Oliveira@eideticom.com>,
Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: P2PDMA in Userspace RDMA
Date: Thu, 9 May 2024 11:31:33 -0600 [thread overview]
Message-ID: <fa2d39cf-b0df-4674-979d-b775d5077bce@deltatee.com> (raw)
Hi Jason,
We've become interested again in enabling P2PDMA transactions with
userspace RDMA and the NVMe CMBs we are already exporting to userspace
from our previous work.
Enabling FOLL_PCI_P2PDMA in ib_umem_get is almost a trivial change, but
there are two issues holding us back.
The biggest issue is that we disallowed FOLL_LONGTERM with
FOLL_PCI_P2PDMA out of concern that P2PDMA had the same problem as
fs-dax. See [1] to review the discussion from 2 years ago. However, in
trying to understand the problem again, I'm not sure that concern was
valid. In P2PDMA, unmap_mapping_range() is strictly only called on
driver unbind when everything is getting torn down[2]. The next thing
that happens immediately after the unmap is the tear down of the pgmap
which drops the elevated reference on the pages and waits for all page's
reference counts to go back to zero. This will effectively wait until
all longterm pins involving the memory have been released. This can
cause a hang on unbind but, in your words, its "annoying not critical".
Even if unmap_mapping_range() was happening outside of teardown, the
P2PDMA code isn't like a regular filesystem in that it fully supports
the elevated reference counts in the pgmap code and pages cannot be
reused until the pin releases its reference counts and the count returns
back to one. So I don't really see how there can be a UAF concern with this.
Unless I'm really missing something, it seems P2PDMA does not have the
same concern as fs-dax and I think it is safe to remove that
restriction. Any objections?
The other issue we hit when enabling this feature is the check for
vma_needs_dirty_tracking() in writable_file_mapping_allowed() during the
gup flow. This hits because the p2pdma code is using the common
sysfs/kernfs infrastructure to create the VMA which installs a
page_mkwrite operator()[4] to change the file update time on write. I
don't think this feature really makes any sense for the P2PDMA sysfs
file which is really operating as an allocator in userspace -- the time
on the file does not really need to reflect the last write of some
process that wrote to memory allocated using it. So I think removing the
operator for P2PDMA makes sense, it's just a matter of creating the
plumbing that allows P2PDMA to indicate this to kernfs. There may be a
certain amount of bikeshedding on how this might be done, but it doesn't
seem terribly complicated.
Thoughts?
Logan
[1] https://lore.kernel.org/all/Yy4Ot5MoOhsgYLTQ@ziepe.ca/T/#u
[2] https://elixir.bootlin.com/linux/v6.8.8/source/drivers/pci/p2pdma.c#L333
[3] https://elixir.bootlin.com/linux/v6.8.8/source/mm/gup.c#L1029
[4] https://elixir.bootlin.com/linux/v6.8.8/source/fs/kernfs/file.c#L435
next reply other threads:[~2024-05-09 17:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 17:31 Logan Gunthorpe [this message]
2024-05-09 17:42 ` P2PDMA in Userspace RDMA Jason Gunthorpe
2024-05-09 20:48 ` Alistair Popple
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=fa2d39cf-b0df-4674-979d-b775d5077bce@deltatee.com \
--to=logang@deltatee.com \
--cc=Martin.Oliveira@eideticom.com \
--cc=dan.j.williams@intel.com \
--cc=hch@lst.de \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).