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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Sep 22, 2026 at 03:31:07PM -0700, Alex Mastro wrote:

> So I empathize with Matt's contention that the _existing_ behavior that the
> priv->revoked flag represents is actually "temporarily revoked": the importer
> can use the same dma-buf again, later, without having to re-import
> it!

mlx5 isn't a revoking importer, it is move capable. So the above
sequence isn't a revoke, it is a move with an unmapped placement for a
while.

This is why "temporarily revoked" is a confusing phrase.

The API is such that move and revoke importers can co-exist like this
but they experiance a different version of things..

We probably should not have made it have this move compatible
restoration and had things more consistent. User space can't know if
the importer is move capable or not so it has to assume revoke and it
has to go and unmap things before resetting/etc.

> This series doesn't intend to change the behavior of either. Is the confusion
> about whether the current behavior is intentional and/or desirable? If the
> answer to both is "no", then IMO this series paves the way nicely towards making
> PERM_REVOKED the only supported semantic later.

Right, I think the only concern is language.

Jason