From: Jason Gunthorpe <jgg@nvidia.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Matt Evans" <matt@ozlabs.org>,
"Leon Romanovsky" <leon@kernel.org>,
"Alex Williamson" <alex@shazbot.org>,
"Alex Mastro" <amastro@fb.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Logan Gunthorpe" <logang@deltatee.com>,
"Kevin Tian" <kevin.tian@intel.com>,
"Pranjal Shrivastava" <praan@google.com>,
"Longfang Liu" <liulongfang@huawei.com>,
"Mahmoud Adam" <mngyadam@amazon.de>,
"David Matlack" <dmatlack@google.com>,
"Björn Töpel" <bjorn@kernel.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Ankit Agrawal" <ankita@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Vivek Kasireddy" <vivek.kasireddy@intel.com>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v6 9/9] vfio/pci: Permanently revoke a DMABUF on request
Date: Mon, 21 Sep 2026 10:49:24 -0300 [thread overview]
Message-ID: <20260921134924.GB1507824@nvidia.com> (raw)
In-Reply-To: <fa5c7fd5-f24a-4ca1-89c3-9ccd9a728fb4@amd.com>
On Mon, Sep 21, 2026 at 03:45:28PM +0200, Christian König wrote:
> > The right way to view this flow is VFIO permanently revokes the DMABUF
> > FD. Then instead of forcing a new FD to be obtained it replaces the
> > existing FD with a working one.
>
> Well that is a little bit problematic. It could result in a race
> when you have multiple importers.
This is all a "kernel protection" scheme for VFIO. VFIO userspace is
expected to have unmapped things and is not expected to do mappings
while also doing FLR.
The only kernel goal here is to maintain kernel integrity, not to have
well defined semantics for illegal racy userspace behavior.
So from that perspective the races are OK.
> > That VFIO re-used the FD to make a new live export isn't visible to
> > the importer at all.
> >
> > I think that is where this "temporary revoke" language gets confusing.
> >
> > Call it "VFIO reuses the FD to create a new live mapping" is clearer
> > than calling it "temporarily revoke" which sounds too much like move.
>
> I would avoid that and just re-create the DMA-buf fd from
> scratch. The extra overhead is negligible and one way state
> transmissions are usually much easier to handle.
Yeah, maybe we should have done that. Might be too late now.
Jason
next prev parent reply other threads:[~2026-09-21 13:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 21:41 [PATCH v6 0/9] vfio/pci: Add mmap() for DMABUFs Matt Evans
2026-09-11 21:41 ` [PATCH v6 1/9] vfio/pci: Remove DMABUF export dependency on vdev->memory_lock Matt Evans
2026-09-11 21:41 ` [PATCH v6 2/9] vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume Matt Evans
2026-09-11 21:41 ` [PATCH v6 3/9] dma-buf: Export dma_buf_set_name() Matt Evans
2026-09-14 11:06 ` Christian König
2026-09-15 13:35 ` Matt Evans
2026-09-11 21:41 ` [PATCH v6 4/9] vfio/pci: Add a helper to look up PFNs for DMABUFs Matt Evans
2026-09-11 21:41 ` [PATCH v6 5/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA Matt Evans
2026-09-15 12:16 ` liulongfang
2026-09-21 13:24 ` Matt Evans
2026-09-11 21:41 ` [PATCH v6 6/9] vfio/pci: Convert BAR mmap() to use a DMABUF Matt Evans
2026-09-11 21:41 ` [PATCH v6 7/9] vfio/pci: Clean up BAR zap and revocation Matt Evans
2026-09-11 21:41 ` [PATCH v6 8/9] vfio/pci: Support mmap() of a VFIO DMABUF Matt Evans
2026-09-11 21:41 ` [PATCH v6 9/9] vfio/pci: Permanently revoke a DMABUF on request Matt Evans
2026-09-13 16:52 ` Leon Romanovsky
2026-09-14 11:36 ` Jason Gunthorpe
2026-09-14 11:54 ` Leon Romanovsky
2026-09-14 11:58 ` Jason Gunthorpe
2026-09-14 12:06 ` Leon Romanovsky
2026-09-14 12:08 ` Jason Gunthorpe
2026-09-14 12:13 ` Matt Evans
2026-09-15 7:20 ` Leon Romanovsky
2026-09-15 11:13 ` Christian König
2026-09-15 14:22 ` Matt Evans
2026-09-16 14:19 ` Christian König
2026-09-21 13:08 ` Matt Evans
2026-09-21 13:22 ` Jason Gunthorpe
2026-09-21 13:45 ` Christian König
2026-09-21 13:49 ` Jason Gunthorpe [this message]
2026-09-21 14:09 ` Christian König
2026-09-15 12:35 ` Jason Gunthorpe
2026-09-15 14:30 ` Matt Evans
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=20260921134924.GB1507824@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex@shazbot.org \
--cc=amastro@fb.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dmatlack@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liulongfang@huawei.com \
--cc=logang@deltatee.com \
--cc=matt@ozlabs.org \
--cc=mngyadam@amazon.de \
--cc=praan@google.com \
--cc=sumit.semwal@linaro.org \
--cc=vivek.kasireddy@intel.com \
/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
all inboxes | Powered by JetHome®