Re: [PATCH v6 9/9] vfio/pci: Permanently revoke a DMABUF on request

[Leon Romanovsky <leon@kernel.org>]

On Mon, Sep 14, 2026 at 08:36:47AM -0300, Jason Gunthorpe wrote:
> On Sun, Sep 13, 2026 at 07:52:44PM +0300, Leon Romanovsky wrote:
> > On Fri, Sep 11, 2026 at 10:41:57PM +0100, Matt Evans wrote:
> > > Expand the VFIO DMABUF revocation state to three states:
> > > Not revoked, temporarily revoked, and permanently revoked.
> > 
> > The thing is that "temporarily revoked" is actually the standard
> > invalidate_mappings/move_notify mechanism of DMABUF, which wasn't good
> > for VFIO.
> 
> I think temporarily revokes here means it is revoked from a dmabuf
> perspective

My guess is that this is more of a "change owner" operation than a
revoke operation.

The main issue here is that we have to guess the semantics instead of
having a properly named and documented operation. As Christian pointed
out, the patches describe what they are doing well, but they do not
explain why they are doing it.

> 
> Just that VFIO can make it's internal dmabuf work again, there won't
> be a notification to any importer or an expectation that something
> like iommufd will re-establish mapping automatically.
> 
> This is principally a kernel self protection mechanism where the
> userspace was expected to have removed the dmabuf before issuing a
> reset/etc. If they didn't then the kernel plonks it and userspace gets
> a mess to clean up.

Revoke/invalidate means that the importer should stop accessing the
buffer provided by the exporter. It does not specify what the exporter
should do afterwards.

So I still think that "temporarily revoked" is closer to
invalidate_mappings, with some additional dma-buf documentation to lose
the expectation that the buffer will become available again.

Thanks

> 
> Jason