On Tue, 6 Oct 2026 20:36:29 +0100 Matt Evans <[email protected]> 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).
