On Fri, Oct 17, 2025 at 12:58:50PM -0300, Jason Gunthorpe wrote:
On Fri, Oct 17, 2025 at 08:40:07AM +0300, Leon Romanovsky wrote:
+static void vfio_pci_dma_buf_detach(struct dma_buf *dmabuf,
struct dma_buf_attachment *attachment)+{
- kfree(attachment->priv);
+}
If the caller fails to call map then it leaks the iova.
I'm relying on dmabuf code and documentation:
926 /** 927 * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list ... 932 * 933 * Returns struct dma_buf_attachment pointer for this attachment. Attachments 934 * must be cleaned up by calling dma_buf_detach().
Successful call to vfio_pci_dma_buf_attach() MUST be accompanied by call to vfio_pci_dma_buf_detach(), so as far as dmabuf implementation follows it, there is no leak.
It leaks the ivoa because there is no dma_iova_destroy() unless you call unmap. detach is not unmap and unmap is not mandatory to call.
Though putting iova free in detach is problematic for the hot-unplug case. In that instance we need to ensure the iova is cleaned up prior to returning from vfio's remove(). detached is called on the importers timeline but unmap is required to be called in move_notify..
So I guess some kind of flag to trigger the unmap after cleanup to free the iova?
Jason