Re: [PATCH v7 9/9] vfio/pci: Revoke a DMABUF on request from userspace

[sashiko-bot@kernel.org]

> Replace the VFIO exporter's priv->revoked flag with a status enum of
> OK, REVOKED, and DEAD.  OK and REVOKED are equivalent to the existing
> flag, which tracks whether invalidate_mappings & unmap has occurred
> and whether attach/map are permitted.
> 
> The DMABUF is marked DEAD in response to a new VFIO feature
> VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE.  This passes a DMABUF by fd and
> requests that the DMABUF is immediately revoked.  On success, it's
> guaranteed that PTEs are zapped, imports have been cleanly unmapped,
> and that the buffer can never be mapped/attached or mmap()ed anymore.
> Existing VFIO move semantics could permit a buffer to be mapped again
> in future (e.g. revoke/unrevoke around a reset), but the DEAD state
> can never become OK again.
> 
> This enables a userspace driver process to securely reclaim VFIO PCI
> BAR resources previously delegated to a subordinate process.  Using
> the new ioctl, the userspace driver process can ensure that resources
> are inaccessible when the subordinate is deemed "done".  The
> originally-exported DMABUF becomes unusable, and BAR resources can
> then be safely re-exported for use elsewhere.
> 
> Refactor the revocation code out of vfio_pci_dma_buf_move() to a
> function common to move and the new feature request path.  This
> function calls dma_buf_invalidate_mappings() and
> dma_resv_wait_timeout() only on the revoke path
> (vfio_pci_dma_buf_move() originally called them for both revoke and,
> unnecessarily, for un-revoke).
> 
> Signed-off-by: Matt Evans <matt@ozlabs.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924152159.49702-1-matt@ozlabs.org?part=9