Hi Jason, On 15/09/2026 13:35, Jason Gunthorpe wrote: > On Mon, Sep 14, 2026 at 01:13:36PM +0100, Matt Evans wrote: >> "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." > > This makes the point clear, you want a way to permanently revoke a > specific dmabuf fd and render it forever unable to access any > underlying memory. > > You want to do this so the vendor can fence the vendee without > requiring its co-operation.
Exactly! (I'll reword this commit message still, re other requests in this thread, but you got the concept.) > "temporary revoke" ie what VFIO already does around reset is a > different thing. Yes, right. From the DMABUF importer (and now mmap) perspective the mechanism is unchanged. priv->revoked was always "temporary"/transient (OK, splitting hairs, but at VFIO shutdown an exported DMABUF becomes permanently inaccessible). Here the only change is adding another cause of becoming inaccessible (direct request from userspace) and the length of time (it can never be re-attached, for the reasons you mentioned). Cheers, Matt
