linux-kernel - Re: [PATCH v2 11/22] iommufd: Add for-driver helpers iommufd_vcmdq

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aBEIBKdjuecVHgpU@Asurada-Nvidia>
Date: Tue, 29 Apr 2025 10:10:28 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Pranjal Shrivastava <praan@...gle.com>
CC: <jgg@...dia.com>, <kevin.tian@...el.com>, <corbet@....net>,
	<will@...nel.org>, <bagasdotme@...il.com>, <robin.murphy@....com>,
	<joro@...tes.org>, <thierry.reding@...il.com>, <vdumpa@...dia.com>,
	<jonathanh@...dia.com>, <shuah@...nel.org>, <jsnitsel@...hat.com>,
	<nathan@...nel.org>, <peterz@...radead.org>, <yi.l.liu@...el.com>,
	<mshavit@...gle.com>, <zhangzekun11@...wei.com>, <iommu@...ts.linux.dev>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-tegra@...r.kernel.org>,
	<linux-kselftest@...r.kernel.org>, <patches@...ts.linux.dev>,
	<mochs@...dia.com>, <alok.a.tiwari@...cle.com>, <vasant.hegde@....com>
Subject: Re: [PATCH v2 11/22] iommufd: Add for-driver helpers
 iommufd_vcmdq_depend/undepend()

On Tue, Apr 29, 2025 at 12:40:07PM +0000, Pranjal Shrivastava wrote:
> On Fri, Apr 25, 2025 at 10:58:06PM -0700, Nicolin Chen wrote:
> >  /* Caller should xa_lock(&viommu->vdevs) to protect the return value */
> >  struct device *iommufd_viommu_find_dev(struct iommufd_viommu *viommu,
> >  				       unsigned long vdev_id)
> 
> If I'm getting this right, I think we are setting up dependencies like:
> vcmdq[2] -> vcmdq[1] -> vcmdq[0] based on refcounts of each object,
> which ensures that the unmaps happen in descending order..

Yes.

> If that's right, Is it fair to have iommufd_vcmdq_depend/undepend in the
> core code itself? Since it's a driver-level limitation, I think we
> should just have iommufd_object_depend/undepend in the core code and the
> iommufd_vcmdq_depend/undepend can move into the CMDQV driver?

The moment we added iommufd_object_depend/undepend, we already had
a blur boundary here since we had no choice to handle in the driver
but to ask core for help.

The iommufd_vcmdq_depend/undepend is just a pair of macros to help
validating the structure inputs that are core defined. It is quite
fair to put next to the raw functions. I also had the notes on top
of the raw functions suggesting callers to use the macros instead.

Thanks
Nicolin