On Wed, Sep 23, 2026 at 04:40:03PM +0100, Matt Evans wrote: > Hi Jason, Alex, > > On 22/09/2026 23:57, Jason Gunthorpe wrote: > > 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.. > > Ahhhhh. That was very helpful (esp. to contrast with the previous > iommufd statement about invalidate_mappings being permanent), thank you! > > So the worry was that the VFIO DMABUF's temp/perm state could be > misconstrued as an implication/guarantee about the future availability > of that DMABUF to importers, OK. And we want the existing move(false) > behaviour still, for dynamic importers that treat it as a move.
This is not a bug; the behavior is intentional. During review of the initial versions of the revoke mechanism, it was pointed out that `move_notify == invalidate_mappings == revoke`. The initial versions introduced a separate function call for revocation, which we abandon in favour of move semantics. Thanks
