Re: [RFC PATCH] iommufd: Destroy vdevice on device unbind

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Jason Gunthorpe <jgg@ziepe.ca> writes:

> On Fri, Jun 13, 2025 at 07:31:48AM +0000, Tian, Kevin wrote:
>> yeah that seems to be the option if the said life-cycle dependency
>> cannot be removed...
>> 
>> conceptually it's still a bit unclean as the user needs to know that
>> the vdevice object is special after idevice is unbound i.e. it can only
>> be destroyed instead of supporting any other kind of operations.
>
> I would say userspace is somewhat malfunctioning if it destroys vfio
> before the vdevice. So the main aim here should be to contain the
> resulting mess, but still expect userspace to destroy the vdevice
> without a failure.
>

The destruction of the vdevice is triggered by the .release method of
the iommufd file operations(iommufd_fops_release())

and the destruction of the idevice is driven by the .release method of
vfio cdev.

    vfio_device_fops_release()
    → vfio_df_device_last_close()
    → vfio_iommufd_physical_unbind()
    → iommufd_device_unbind()

The vfio subsystem also retains a reference to the iommufd file descriptor through:

    vfio_df_ioctl_bind_iommufd()
    → iommufd_ctx_from_fd()

This reference prevents the vdevice from being destroyed while the idevice remains bound.

So, IIUC, the current destruction flow is: first destroy vfio, and then destroy the vdevice?

>
>> hmm if the user needs to build certain knowledge anyway can we 
>> go one step further to state that the vdevice will be destroyed
>> automatically once its idevice is unbound so the user shouldn't
>> attempt to explicitly destroy it again after unbind?
>
> I would assume a malfunctioning userspace is probably going to destroy
> the vdevice explicitly. If it had proper knowledge it wouldn't have
> done this in the first place :)
>
> Jason

-aneesh