linux-kernel - Re: [PATCH v1 02/20] iommu: Introduce a test

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: <aPaExVobV9evs22n@Asurada-Nvidia>
Date: Mon, 20 Oct 2025 11:51:49 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: <joro@...tes.org>, <kevin.tian@...el.com>,
	<suravee.suthikulpanit@....com>, <will@...nel.org>, <robin.murphy@....com>,
	<sven@...nel.org>, <j@...nau.net>, <jean-philippe@...aro.org>,
	<robin.clark@....qualcomm.com>, <dwmw2@...radead.org>,
	<baolu.lu@...ux.intel.com>, <yong.wu@...iatek.com>, <matthias.bgg@...il.com>,
	<angelogioacchino.delregno@...labora.com>, <tjeznach@...osinc.com>,
	<pjw@...nel.org>, <palmer@...belt.com>, <aou@...s.berkeley.edu>,
	<heiko@...ech.de>, <schnelle@...ux.ibm.com>, <mjrosato@...ux.ibm.com>,
	<wens@...e.org>, <jernej.skrabec@...il.com>, <samuel@...lland.org>,
	<thierry.reding@...il.com>, <jonathanh@...dia.com>, <iommu@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <asahi@...ts.linux.dev>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-arm-msm@...r.kernel.org>,
	<linux-mediatek@...ts.infradead.org>, <linux-riscv@...ts.infradead.org>,
	<linux-rockchip@...ts.infradead.org>, <linux-s390@...r.kernel.org>,
	<linux-sunxi@...ts.linux.dev>, <linux-tegra@...r.kernel.org>,
	<virtualization@...ts.linux.dev>, <patches@...ts.linux.dev>
Subject: Re: [PATCH v1 02/20] iommu: Introduce a test_dev domain op and an
 internal helper

On Mon, Oct 20, 2025 at 01:27:36PM -0300, Jason Gunthorpe wrote:
> On Sun, Oct 12, 2025 at 05:04:59PM -0700, Nicolin Chen wrote:
> 
> > And keep them within the group->mutex, so drivers can simply move all the
> > sanity and compatibility tests from their attach_dev callbacks to the new
> > test_dev callbacks without concerning about a race condition.
> 
> I'm not sure about this.. For the problem we are trying to solve this
> would be racy as the test would be done and the group mutex
> unlocked. Then later it will be re-tested and attached.

Oh right, we'll have to retest in iommu_dev_reset_done(). I missed
that.

> > @@ -751,6 +760,8 @@ struct iommu_ops {
> >   * @free: Release the domain after use.
> >   */
> >  struct iommu_domain_ops {
> > +	int (*test_dev)(struct iommu_domain *domain, struct device *dev,
> > +			ioasid_t pasid, struct iommu_domain *old);
> 
> Because of the starting remark I'm skeptical that old should be
> included here.

Hmm, the followings functions sanitizes "old":
 - qcom_iommu_identity_attach() drivers/iommu/arm/arm-smmu/qcom_iommu.c
 - iommu_sva_set_dev_pasid() in drivers/iommu/amd/pasid.c

Thanks
Nicolin