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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aA/GPHRvhXi3CLZQ@Asurada-Nvidia>
Date: Mon, 28 Apr 2025 11:17:32 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Baolu Lu <baolu.lu@...ux.intel.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>, <praan@...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 Mon, Apr 28, 2025 at 10:22:09AM +0800, Baolu Lu wrote:
> On 4/26/25 13:58, Nicolin Chen wrote:
> > NVIDIA Virtual Command Queue is one of the iommufd users exposing vIOMMU
> > features to user space VMs. Its hardware has a strict rule when mapping
> > and unmapping multiple global CMDQVs to/from a VM-owned VINTF, requiring
> > mappings in ascending order and unmappings in descending order.
> > 
> > The tegra241-cmdqv driver can apply the rule for a mapping in the LVCMDQ
> > allocation handler, however it can't do the same for an unmapping since
> > the destroy op returns void.
> 
> The key point is that unmapping happens during object destroy. These
> depend/undepend helpers ensure a vCMDQ is not destroyed (and therefore
> unmapped) before any vCMDQs that depend on it. Do I get it right?

Yea, I should add some additional words:
"
The tegra241-cmdqv driver can apply the rule for a mapping in the LVCMDQ
allocation handler. However, it can't do the same for an unmapping since
user space could start random destroy calls breaking the rule, while the
destroy op in the driver level can't reject a destroy call as it returns
void.

Add iommufd_vcmdq_depend/undepend() for-driver helpers, allowing LVCMDQ
allocator to refcount_inc() a sibling LVCMDQ object and LVCMDQ destroyer
to refcount_dec(), so that iommufd core will help block a random destroy
call that breaks the rule.
"

Thanks
Nicolin