On Wed, Jun 04, 2025 at 02:10:43PM +0530, Aneesh Kumar K.V wrote:

Jason Gunthorpe jgg@nvidia.com writes:

...

On Tue, Jun 03, 2025 at 02:20:51PM +0800, Xu Yilun wrote:

...

...

Wouldn’t it be simpler to skip the reference count increment altogether and just call tsm_unbind in the virtual device’s destroy callback? (iommufd_vdevice_destroy())

The vdevice refcount is the main concern, there is also an IOMMU_DESTROY ioctl. User could just free the vdevice instance if no refcount, while VFIO is still in bound state. That seems not the correct free order.

Freeing the vdevice should automatically unbind it..

One challenge I ran into during implementation was the dependency of vfio on iommufd_device. When vfio needs to perform a tsm_unbind, it only has access to an iommufd_device.

VFIO should never do that except by destroying the idevice..

However, TSM operations like binding and unbinding are handled at the iommufd_vdevice level. The issue? There’s no direct link from iommufd_device back to iommufd_vdevice.

Yes.

To address this, I modified the following structures:

modified drivers/iommu/iommufd/iommufd_private.h @@ -428,6 +428,7 @@ struct iommufd_device { /* protect iopf_enabled counter */ struct mutex iopf_lock; unsigned int iopf_enabled;

• struct iommufd_vdevice *vdev;

};

Locking will be painful:

Updating vdevice->idev requires holding vdev->mutex (vdev_lock). Updating device->vdev requires idev->igroup->lock (idev_lock).

I wonder if that can work on the destory paths..

You also have to prevent more than one vdevice from being created for an idevice, I don't think we do that today.

tsm_unbind in vdevice_destroy:

vdevice_destroy() ends up calling tsm_unbind() while holding only the vdev_lock. At first glance, this seems unsafe. But in practice, it's fine because the corresponding iommufd_device has already been destroyed when the VFIO device file descriptor was closed—triggering vfio_df_iommufd_unbind().

This needs some kind of fixing the idevice should destroy the vdevices during idevice destruction so we don't get this out of order where the idevice is destroyed before the vdevice.

This should be a separate patch as it is an immediate bug fix..

Jason