Hi Alex,
On 14/10/2026 00:14, Alex Williamson wrote:
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,
Yes right, that's good to capture here.
The new lifecycle is then _only_ coupled to the revocation state both
(with this patch) at creation time and (already) thereafter.
We sorta have two mechanisms to track "BARs accessible", via
__vfio_pci_memory_enabled() and the changes initiated by
vfio_pci_dma_buf_move() (which already exist, but the new
vdev->bars_revoked flag now tracks). They shouldn't really differ, i.e.
a BAR is accessible or not (whether by CPU or P2P) and we should clean
this up in future. In this patch, creating it from the bars_revoked
state makes the state consistently set from one place, at least.
Cheers,
Matt
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).
