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