On Tue, 6 Oct 2026 20:36:29 +0100 Matt Evans matt@ozlabs.org wrote:
The VFIO_DEVICE_FEATURE_DMA_BUF export previously used vdev->memory_lock to protect VFIO's list of exported DMABUFs (vdev->dmabufs) and their revocation status. When adding a new export, memory_lock was taken for write.
A future commit will refactor DMABUF export into a function used from mmap(), which would create a new mmap_lock -> memory_lock dependency.
In preparation, this commit introduces a vdev->dmabuf_lock that protects the dmabufs list, per-DMABUF revocation state, and a new bars_revoked flag. The flag tracks the device-wide BAR revocation state set via vfio_pci_dma_buf_move() under dmabuf_lock, removing the test of __vfio_pci_memory_enabled() and dependency on vdev->memory_lock.
There's a subtle change here that I'm not sure is worth mentioning, so I'll at least put it on the list for posterity. The initial revoked state of a newly minted DMABUF is now governed by the device-wide BAR revocation state set via vfio_pci_dma_buf_move(). This is subtly different from the current behavior where the initial state is based on instantaneous BAR accessibility tested under vdev->memory_lock. Thanks,
Alex
This is a cleanup currently, but allows the future export path to avoid holding memory_lock under mmap_lock and a therefore avoid a deadlock scenario (a fault handler attempting to take mmap_lock in a vfio-pci variant driver thread that holds memory_lock, vs another thread doing an mmap/export holding them both in the other order).