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

[Tian, Kevin]

> From: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxx>
> Sent: Monday, June 16, 2025 12:15 PM
> 
> "Tian, Kevin" <kevin.tian@xxxxxxxxx> writes:
> 
> >> From: Jason Gunthorpe <jgg@xxxxxxxx>
> >> Sent: Friday, June 13, 2025 1:27 AM
> >>
> >> On Thu, Jun 12, 2025 at 08:05:37AM +0000, Tian, Kevin wrote:
> >> > The initial v5 patch [1] from Nicolin was similar to what this
> >> > patch does. Jason explained [2] why it's unsafe to destroy "userspace
> >> > created" objects behind the scene. And a general rule in iommufd is
> >> > to not take long term references on kernel owned objects.
> >> >
> >> > [1]
> >>
> https://lore.kernel.org/all/53025c827c44d68edb6469bfd940a8e8bc6147a5.1
> >> 729897278.git.nicolinc@xxxxxxxxxx/
> >> > [2] https://lore.kernel.org/all/20241029184801.GW6956@xxxxxxxxxx/
> >>
> >> Yes, we have a problem here where we both can't let VFIO go away while
> >> the vdevice is present nor can we let the vdevice be fully deleted.
> >>
> >> At that point it wasn't such a big deal, but the new stuff seems to
> >> make vdevice more complicated that it cannot out live the idevice.
> >>
> >> Probably the answer is to tombstone the vdevice in the xarray so the
> >> ID is still there and userspace can still destroy it while destroying
> >> everything linked to it?
> >>
> >
> > 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.
> >
> > 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?
> 
> That is what this patch is does. ie, it automatically destroy the
> vdevice while unbinding the idevice.
> 

plus update of the uAPI description if going this route