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

[Matt Evans <matt@ozlabs.org>]

Hi Leon,

On 14/09/2026 12:54, Leon Romanovsky wrote:
> 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. 

Apologies if the cover letter for the series and patch commit message 
(which cover this) are unclear about the motivations and semantics.  On 
the commit message, can you suggest clarifications:

"This is useful for lifecycle management, to reclaim VFIO PCI BAR
ranges previously delegated to a subordinate client process: by
revoking, the driver process can ensure that the loaned resources are
made inaccessible when the client is deemed "done".  The original
DMABUF is defunct, and BAR resources can then be safely re-exported
for use by new clients."

Given what I'll explain below, do give suggestions please.  There is 
more context in the cover letter (the volume of which I didn't think 
appropriate for the commit message).

> As Christian pointed
> out, the patches describe what they are doing well, but they do not
> explain why they are doing it.

His comment may be warranted on the other, new, patch for DMABUF name, 
but I don't think this applies here.

>> 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.

You are right in indicating in your previous email that the "temporarily 
revoked" state is the old "revoked" state.

 From the DMABUF importer interactions, there's _still_ only "revoked or 
not revoked" state.  No changes there.

 From this VFIO exporter's perspective, the change is to add a "sticky" 
revoked state.

The thing (as per UAPI docs, again I hope there's no guessing needed) 
that the new third state gives is that a) userspace can explicitly 
request it via the new ioctl/feature, and b) it is guaranteed not to be 
spuriously or intentionally undone by anyone else.

E.g. reset:  temporarily revoke, then un-revoke.   New ioctl: 
permanently revoke, such that something like a subsequent reset isn't 
going to undo it and make the DMABUF usable again.

The usage scenario is:

1. Process A exports DMABUF from VFIO device.  (Proc A is the 
"orchestrator" here.)
2. Process A sends fd to process B.
3. Process B maps it, or hands it on, etc.
4. Process A eventually decides the buffer is finished with/lifecycle 
done/wants to reuse that BAR range for something else.  It permanently 
revokes the DMABUF.
5. Hopefully this isn't a surprise to B (some cooperation has given it 
up first) but either way, B now cannot access the BAR range anymore. 
This does not _need_ cooperation, so if B becomes malicious, or crashes, 
etc. A can still revoke it.
6. That BAR range is reused for something unrelated.


HTH,


Matt