Hi Alex,
On 29/07/2026 18:52, Alex Williamson wrote:
> On Wed, 15 Jul 2026 18:47:29 +0100
> Matt Evans <[email protected]> wrote:
>
>> Since converting BAR mmap()s to using DMABUFs, we lose the original
>> device path in /proc/<pid>/maps, lsof, etc. Generate a debug-oriented
>> synthetic 'filename' based on the cdev, plus BDF, plus resource index.
>>
>> This applies only to BAR mappings via the VFIO device fd, as
>> explicitly-exported DMABUFs are named by userspace via the
>> DMA_BUF_SET_NAME ioctl.
>>
>> Signed-off-by: Matt Evans <[email protected]>
>> Reviewed-by: Pranjal Shrivastava <[email protected]>
>> ---
>> drivers/vfio/pci/vfio_pci_dmabuf.c | 22 ++++++++++++++++++++--
>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c
>> b/drivers/vfio/pci/vfio_pci_dmabuf.c
>> index 46b3cf5dc94b..51606ff3cdc6 100644
>> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
>> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
>> @@ -4,6 +4,7 @@
>> #include <linux/dma-buf-mapping.h>
>> #include <linux/pci-p2pdma.h>
>> #include <linux/dma-resv.h>
>> +#include <uapi/linux/dma-buf.h>
>
> Is this required? It seems unused.
No, good catch. That originally pulled in DMA_BUF_NAME_LEN in the
previous version snprintf'ing here. Removed.
>>
>> #include "vfio_pci_priv.h"
>>
>> @@ -486,6 +487,7 @@ int vfio_pci_core_mmap_prep_dmabuf(struct
>> vfio_pci_core_device *vdev,
>> {
>> struct vfio_pci_dma_buf *priv;
>> unsigned long vma_pgoff = vma->vm_pgoff & (VFIO_PCI_OFFSET_MASK >>
>> PAGE_SHIFT);
>> + char *bufname;
>> int ret;
>>
>> priv = kzalloc_obj(*priv);
>> @@ -498,6 +500,15 @@ int vfio_pci_core_mmap_prep_dmabuf(struct
>> vfio_pci_core_device *vdev,
>> goto err_free_priv;
>> }
>>
>> + bufname = kasprintf(GFP_KERNEL, "%s:%s/%x",
>> + dev_name(&vdev->vdev.device), pci_name(vdev->pdev),
>> + res_index);
>> +
>> + if (!bufname) {
>> + ret = -ENOMEM;
>> + goto err_free_phys;
>> + }
>> +
>> /*
>> * The DMABUF begins from the mmap()'s BAR offset, i.e. the
>> * start of the VMA corresponds to byte 0 of the DMABUF and
>> @@ -516,7 +527,7 @@ int vfio_pci_core_mmap_prep_dmabuf(struct
>> vfio_pci_core_device *vdev,
>> priv->provider = pcim_p2pdma_provider(vdev->pdev, res_index);
>> if (!priv->provider) {
>> ret = -EINVAL;
>> - goto err_free_phys;
>> + goto err_free_name;
>> }
>>
>> priv->phys_vec[0].paddr = phys_start + ((u64)vma_pgoff << PAGE_SHIFT);
>> @@ -524,7 +535,7 @@ int vfio_pci_core_mmap_prep_dmabuf(struct
>> vfio_pci_core_device *vdev,
>>
>> ret = vfio_pci_dmabuf_export(vdev, priv, O_CLOEXEC | O_RDWR);
>> if (ret)
>> - goto err_free_phys;
>> + goto err_free_name;
>>
>> /*
>> * Ownership of the DMABUF file transfers to the VMA so that
>> @@ -539,8 +550,15 @@ int vfio_pci_core_mmap_prep_dmabuf(struct
>> vfio_pci_core_device *vdev,
>> vma->vm_file = priv->dmabuf->file;
>> vma->vm_private_data = priv;
>>
>> + spin_lock(&priv->dmabuf->name_lock);
>> + kfree(priv->dmabuf->name);
>> + priv->dmabuf->name = bufname;
>> + spin_unlock(&priv->dmabuf->name_lock);
>
> This is simple, but shouldn't it really have a sanctioned, exported
> dmabuf helper rather than open coding this handling? Thanks,
Hm, okay that's reasonable. I've refactored dma_buf_set_name() and used
it from here (separating out a userspace-string-copying version for the
original ioctl usage).
Thanks for looking at the rest of v5 also.
Matt
>
> Alex
>
>> +
>> return 0;
>>
>> +err_free_name:
>> + kfree(bufname);
>> err_free_phys:
>> kfree(priv->phys_vec);
>> err_free_priv:
>
