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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB527682E21BF2564E5153A5208C70A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 16 Jun 2025 05:48:11 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Aneesh Kumar K.V <aneesh.kumar@...nel.org>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: Jason Gunthorpe <jgg@...pe.ca>, Joerg Roedel <joro@...tes.org>, "Will
 Deacon" <will@...nel.org>, Robin Murphy <robin.murphy@....com>
Subject: RE: [RFC PATCH] iommufd: Destroy vdevice on device unbind

> From: Aneesh Kumar K.V <aneesh.kumar@...nel.org>
> Sent: Monday, June 16, 2025 12:46 PM
> 
> What I described above explains how the kernel manages destruction of
> these objects.
> 
> The vfio subsystem retains a reference to the iommufd file descriptor
> through:
> 
>     vfio_df_ioctl_bind_iommufd() → iommufd_ctx_from_fd()
> 
> This reference prevents the associated vdevice from being destroyed when
> the iommufd file descriptor is closed, as long as the idevice remains
> bound. While vdevice objects can still be explicitly destroyed using
> iommufd_destroy(), with this patch, if the idevice is still bound,
> attempting to destroy the vdevice will return EBUSY.

this is counter-intuitive. My impression from previous discussion was
that the vdevice lifecycle is gated by the idevice (i.e. cannot live
longer) once they are connected, but not that the vdevice can only
be destroyed indirectly via unbind (cannot live shorter)...

If this is a TIO specific requirement it's better to articulate it early.