Re: [PATCH RFC 12/26] vfio/pci: Change the DMA-buf exporter to use mapping_type

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Apr 13, 2026 at 04:29:59PM +0800, Baolu Lu wrote:
> On 2/18/26 08:11, Jason Gunthorpe wrote:
> > Simple conversion to add a match_mapping() callback that offers an
> > exporter SGT mapping type. Later patches will add a physical address
> > exporter so go straight to adding the match_mapping() function.
> > 
> > The check for attachment->peer2peer is replaced with setting
> > exporter_requires_p2p=true. VFIO always uses MMIO memory.
> > 
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> >   drivers/vfio/pci/vfio_pci_dmabuf.c | 31 +++++++++++++++++++++++++-----
> >   1 file changed, 26 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > index d4d0f7d08c53e2..c7addef5794abf 100644
> > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > @@ -25,9 +25,6 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> >   {
> >   	struct vfio_pci_dma_buf *priv = dmabuf->priv;
> > -	if (!attachment->peer2peer)
> > -		return -EOPNOTSUPP;
> > -
> >   	if (priv->revoked)
> >   		return -ENODEV;
> > @@ -75,11 +72,35 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
> >   	kfree(priv);
> >   }
> > -static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
> > -	.attach = vfio_pci_dma_buf_attach,
> > +static const struct dma_buf_mapping_sgt_exp_ops vfio_pci_dma_buf_sgt_ops = {
> >   	.map_dma_buf = vfio_pci_dma_buf_map,
> >   	.unmap_dma_buf = vfio_pci_dma_buf_unmap,
> > +};
> > +
> > +static int vfio_pci_dma_buf_match_mapping(struct dma_buf_match_args *args)
> > +{
> > +	struct vfio_pci_dma_buf *priv = args->dmabuf->priv;
> > +	struct dma_buf_mapping_match sgt_match[1];
> > +
> > +	dma_resv_assert_held(priv->dmabuf->resv);
> 
> My understanding of this lock assertion is that priv and the underlying
> priv->vdev are accessed within this function. Therefore, the lock is
> necessary to protect them. Do I understand it right?

It is because we NULL priv->vdev on the cleanup path

I'm not sure why my test kernel didn't hit lockdep failures but yes
this looks incorrect.

> However, callers - for example, dma_buf_mapping_attach() - do not
> acquire dma_resv_lock() before calling this function. So kernel traces
> will always be triggered.

I think this is the fix:

diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
index 9e7e8e7719d1bd..3e31ffb03ddd9a 100644
--- a/drivers/vfio/pci/vfio_pci_dmabuf.c
+++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
@@ -12,6 +12,7 @@ MODULE_IMPORT_NS("DMA_BUF");
 struct vfio_pci_dma_buf {
 	struct dma_buf *dmabuf;
 	struct vfio_pci_core_device *vdev;
+	struct pci_dev *pdev;
 	struct list_head dmabufs_elm;
 	size_t size;
 	struct phys_vec *phys_vec;
@@ -92,6 +93,7 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
 		up_write(&priv->vdev->memory_lock);
 		vfio_device_put_registration(&priv->vdev->vdev);
 	}
+	pci_dev_put(priv->pdev);
 	kfree(priv->phys_vec);
 	kfree(priv);
 }
@@ -143,18 +145,9 @@ static int vfio_pci_dma_buf_match_mapping(struct dma_buf_match_args *args)
 	struct vfio_pci_dma_buf *priv = args->dmabuf->priv;
 	struct dma_buf_mapping_match sgt_match[2];
 
-	dma_resv_assert_held(priv->dmabuf->resv);
-
-	/*
-	 * Once we pass vfio_pci_dma_buf_cleanup() the dmabuf will never be
-	 * usable again.
-	 */
-	if (!priv->vdev)
-		return -ENODEV;
-
 	sgt_match[0] = DMA_BUF_EMAPPING_PAL(&vfio_pci_dma_buf_pal_ops);
 	sgt_match[1] = DMA_BUF_EMAPPING_SGT_P2P(&vfio_pci_dma_buf_sgt_ops,
-						priv->vdev->pdev);
+						priv->pdev);
 
 	return dma_buf_match_mapping(args, sgt_match, ARRAY_SIZE(sgt_match));
 }
@@ -323,6 +316,7 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
 		goto err_dev_put;
 	}
 
+	priv->pdev = pci_dev_get(vdev->pdev);
 	kref_init(&priv->kref);
 	init_completion(&priv->comp);