linux-kernel - Re: [PATCH v3 5/5] pci: Suspend iommu function prior to resetting a device

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: <aKTzq6SLGB22Xq5b@Asurada-Nvidia>
Date: Tue, 19 Aug 2025 14:59:07 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Ethan Zhao <etzhao1900@...il.com>
CC: <robin.murphy@....com>, <joro@...tes.org>, <bhelgaas@...gle.com>,
	<jgg@...dia.com>, <will@...nel.org>, <robin.clark@....qualcomm.com>,
	<yong.wu@...iatek.com>, <matthias.bgg@...il.com>,
	<angelogioacchino.delregno@...labora.com>, <thierry.reding@...il.com>,
	<vdumpa@...dia.com>, <jonathanh@...dia.com>, <rafael@...nel.org>,
	<lenb@...nel.org>, <kevin.tian@...el.com>, <yi.l.liu@...el.com>,
	<baolu.lu@...ux.intel.com>, <linux-arm-kernel@...ts.infradead.org>,
	<iommu@...ts.linux.dev>, <linux-kernel@...r.kernel.org>,
	<linux-arm-msm@...r.kernel.org>, <linux-mediatek@...ts.infradead.org>,
	<linux-tegra@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
	<linux-pci@...r.kernel.org>, <patches@...ts.linux.dev>,
	<pjaroszynski@...dia.com>, <vsethi@...dia.com>, <helgaas@...nel.org>
Subject: Re: [PATCH v3 5/5] pci: Suspend iommu function prior to resetting a
 device

On Tue, Aug 19, 2025 at 10:12:41PM +0800, Ethan Zhao wrote:
> On 8/12/2025 6:59 AM, Nicolin Chen wrote:
> > @@ -4529,13 +4530,26 @@ EXPORT_SYMBOL(pci_wait_for_pending_transaction);
> >    */
> >   int pcie_flr(struct pci_dev *dev)
> >   {
> > +	int ret = 0;
> > +
> >   	if (!pci_wait_for_pending_transaction(dev))
> >   		pci_err(dev, "timed out waiting for pending transaction; performing function level reset anyway\n");
> > +	/*
> > +	 * Per PCIe r6.3, sec 10.3.1 IMPLEMENTATION NOTE, software disables ATS
> > +	 * before initiating a reset. Notify the iommu driver that enabled ATS.
> > +	 * Have to call it after waiting for pending DMA transaction.
> > +	 */
> > +	ret = iommu_dev_reset_prepare(&dev->dev);

> If we dont' consider the association between IOMMU and devices in FLR(),
> it can be understood that more complex processing logic resides outside
> this function. However, if the FLR() function already synchironizes and
> handles the association with IOMMU like this (disabling ATS by attaching
> device to blocking domain), then how would the following scenarios
> behave ?

That's a good point. The iommu-level reset is per struct device.
So, basically it'll match with the FLR per pci_dev. Yet, the RID
isolation between siblings might be a concern:

> 1. Reset one of PCIe alias devices.

IIRC, an alias device might have:

 a) one pci_dev; multiple RIDs

    In this case, neither FLR nor IOMMU isolates between RIDs.
    So, both FLR and IOMMU blocking will reset all RIDs. There
    should be no issue resulted from the IOMMU blocking.

 b) multiple pci_devs; single RID

    In this case, FLR only resets one device, while the IOMMU-
    level reset will block the entire RID (i.e. all devices),
    since they share the single translation tunnel. This could
    break the siblings, if they aren't also being reset along.

> 2. Reset PF when its VFs are actvie.

 c) multiple pci_devs with their own RIDs

    In this case, either FLR or IOMMU only resets the PF. That
    being said, VFs might be affected since PF is resetting?
    If there is an issue, I don't see it coming from the IOMMU-
    level reset..

Thus, case b might be breaking. So, perhaps we should add a few
conditions when calling iommu_dev_reset_prepare/done():
 + Make sure that the pci_dev has ATS capability
 + Make sure no sibling pci_dev(s) sharing the same RID
 + Any others?

Thanks
Nicolin