linux-kernel - RE: [PATCH 1/1] iommu/vt-d: Fix WARN

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]

Date: Mon, 8 Apr 2024 09:12:11 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>
CC: Jason Gunthorpe <jgg@...pe.ca>, Joerg Roedel <joro@...tes.org>, "Will
 Deacon" <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Bjorn Helgaas
	<helgaas@...nel.org>
Subject: RE: [PATCH 1/1] iommu/vt-d: Fix WARN_ON in iommu probe path

+Bjorn

> From: Baolu Lu <baolu.lu@...ux.intel.com>
> Sent: Monday, April 8, 2024 3:15 PM
> 
> On 2024/4/8 11:52, Tian, Kevin wrote:
> >> From: Lu Baolu<baolu.lu@...ux.intel.com>
> >> Sent: Sunday, April 7, 2024 9:14 AM
> >>
> >> Commit 1a75cc710b95 ("iommu/vt-d: Use rbtree to track iommu probed
> >> devices") adds all devices probed by the iommu driver in a rbtree
> >> indexed by the source ID of each device. It assumes that each device
> >> has a unique source ID. This assumption is incorrect and the VT-d
> >> spec doesn't state this requirement either.
> >>
> >> The reason for using a rbtree to track devices is to look up the device
> >> with PCI bus and devfunc in the paths of handling ATS invalidation time
> >> out error and the PRI I/O page faults. Both are PCI ATS feature related.
> >>
> >> Only track the devices that have PCI ATS capabilities in the rbtree to
> >> avoid unnecessary WARN_ON in the iommu probe path. Otherwise, on
> some
> >> platforms below kernel splat will be displayed and the iommu probe
> results
> >> in failure.
> > Just be curious. What about two ATS capable devices putting behind
> > a PCI-to-PCIe bridge?
> 
> I don't think ATS capable device putting behind a PCI-to-PCIe bridge is
> a right configuration for the ATS service. The PCIe spec requires this
> in section 10.1.1, that
> 
> "
> ATS requires the following:
> - ATS capable components must interoperate with [PCIe-1.1] compliant
>    components.
> ...
> "
> 
> My understanding is that PCI-to-PCIe bridge is not a PCIe compliant
> device.
> 

what is the pci core policy on such device? pci_enable_ats() doesn't
prevent such device and I saw various places in pci core do handle
the PCI_EXP_TYPE_PCIE_BRIDGE type...