linux-kernel - Re: [Patch Part2 V2 15/17] iommu/vt-d, PCI: update DRHD/RMRR/ATSR device scope caches when PCI hotplug happens

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: <1394130319.9994.28.camel@i7.infradead.org>
Date:	Thu, 06 Mar 2014 18:25:19 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	Jiang Liu <jiang.liu@...ux.intel.com>
Cc:	Joerg Roedel <joro@...tes.org>, Yinghai Lu <yinghai@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Vinod Koul <vinod.koul@...el.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
	Tony Luck <tony.luck@...el.com>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org,
	iommu@...ts.linux-foundation.org
Subject: Re: [Patch Part2 V2 15/17] iommu/vt-d, PCI: update DRHD/RMRR/ATSR
 device scope caches when PCI hotplug happens

On Wed, 2014-02-19 at 14:07 +0800, Jiang Liu wrote:
> Current Intel DMAR/IOMMU driver assumes that all PCI devices
> associated
> with DMAR/RMRR/ATSR device scope arrays are created at boot time and
> won't change at runtime, so it caches pointers of associated PCI
> device
> object. That assumption may be wrong now due to:
> 1) introduction of PCI host bridge hotplug
> 2) PCI device hotplug through sysfs interfaces.
...
> This patch introduces a new mechanism to update the DRHD/RMRR/ATSR
> device scope caches by hooking PCI bus notification.

Hm, this seems overly complex. Can't we just abandon the
dmaru->devices[] array completely? In dmar_find_matched_drhd_unit()
can't we just compare the path in the scope entries directly to the PCI
device we are trying to find a DRHD for?

We then cache the result in dev->archdata.iommu for ever (well, until
hot-unplug) anyway, so it shouldn't even be any less efficient to do it
on demand, right?

That's true at least for dmar_find_matched_drhd_unit(). Perhaps we'd
need to find a way to cache the result for
dmar_find_matched_atsr_unit()?

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)