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

["Christian König" <christian.koenig@amd.com>]

On 9/21/26 15:49, Jason Gunthorpe wrote:
> 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.

Yeah as long as userspace can only shoot themselves in the foot it is probably ok.

In this case we just need to make sure that the flag is properly protected by some lock inside the kernel.
>>> 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.

It's already uAPI? 

Christian.

> 
> Jason