linux-kernel - Re: [PATCH v3 1/5] iommu: Lock group->mutex in iommu_deferred

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: <aJ+J05iESNOVm0Kk@Asurada-Nvidia>
Date: Fri, 15 Aug 2025 12:26:11 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
CC: "robin.murphy@....com" <robin.murphy@....com>, "joro@...tes.org"
	<joro@...tes.org>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"jgg@...dia.com" <jgg@...dia.com>, "will@...nel.org" <will@...nel.org>,
	"robin.clark@....qualcomm.com" <robin.clark@....qualcomm.com>,
	"yong.wu@...iatek.com" <yong.wu@...iatek.com>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, "angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>, "thierry.reding@...il.com"
	<thierry.reding@...il.com>, "vdumpa@...dia.com" <vdumpa@...dia.com>,
	"jonathanh@...dia.com" <jonathanh@...dia.com>, "rafael@...nel.org"
	<rafael@...nel.org>, "lenb@...nel.org" <lenb@...nel.org>, "Liu, Yi L"
	<yi.l.liu@...el.com>, "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>, "linux-tegra@...r.kernel.org"
	<linux-tegra@...r.kernel.org>, "linux-acpi@...r.kernel.org"
	<linux-acpi@...r.kernel.org>, "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>, "patches@...ts.linux.dev"
	<patches@...ts.linux.dev>, "Jaroszynski, Piotr" <pjaroszynski@...dia.com>,
	"Sethi, Vikram" <vsethi@...dia.com>, "helgaas@...nel.org"
	<helgaas@...nel.org>, "etzhao1900@...il.com" <etzhao1900@...il.com>
Subject: Re: [PATCH v3 1/5] iommu: Lock group->mutex in iommu_deferred_attach

On Fri, Aug 15, 2025 at 08:24:57AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <nicolinc@...dia.com>
> > Sent: Tuesday, August 12, 2025 6:59 AM
> > 
> > The iommu_deferred_attach() is a runtime asynchronous function called by
> > iommu-dma function, which could race against other attach functions if it
> > accesses something in the dev->iommu_group.
> 
> Is there a real racing scenario being observed or more theoretical?
> 
> If the former may need a Fix tag. 

Theoretical. I will highlight that in next version.

> >  int iommu_deferred_attach(struct device *dev, struct iommu_domain
> > *domain)
> >  {
> > -	if (dev->iommu && dev->iommu->attach_deferred)
> > -		return __iommu_attach_device(domain, dev);
> > +	/*
> > +	 * This is called on the dma mapping fast path so avoid locking. This is
> > +	 * racy, but we have an expectation that the driver will setup its
> > DMAs
> > +	 * inside probe while being single threaded to avoid racing.
> > +	 */
> > +	if (!dev->iommu || !dev->iommu->attach_deferred)
> > +		return 0;
> 
> Is there any way to detect a driver breaking the expectation?

Hmm, I am not sure.. that would sound tricky if we really want to
have a 2nd flag to protect this one..

And this patch doesn't change the race situation, if it does ever
exist..

If we really want to play safe, moving the flag under the lock as
Baolu's suggestion is probably the answer?

Thanks
Nicolin