[PATCH 01/11] iommu: Have __iommu_probe_device() check for already probed devices
Tian, Kevin
kevin.tian at intel.com
Wed Apr 26 19:12:31 AEST 2023
> From: Jason Gunthorpe <jgg at nvidia.com>
> Sent: Thursday, April 20, 2023 12:12 AM
>
> This is a step toward making __iommu_probe_device() self contained.
>
> It should, under proper locking, check if the device is already associated
> with an iommu driver and resolve parallel probes. All but one of the
> callers open code this test using two different means, but they all
> rely on dev->iommu_group.
>
> Currently the bus_iommu_probe()/probe_iommu_group() and
> probe_acpi_namespace_devices() rejects already probed devices with an
> unlocked read of dev->iommu_group. The OF and ACPI "replay" functions
> use
> device_iommu_mapped() which is the same read without the pointless
> refcount.
>
> Move this test into __iommu_probe_device() and put it under the
> iommu_probe_device_lock. The store to dev->iommu_group is in
> iommu_group_add_device() which is also called under this lock for iommu
> driver devices, making it properly locked.
>
> The only path that didn't have this check is the hotplug path triggered by
> BUS_NOTIFY_ADD_DEVICE. The only way to get dev->iommu_group assigned
> outside the probe path is via iommu_group_add_device(). Today there are
> only three callers, VFIO no-iommu, powernv and power pseries - none of
> these cases probe iommu drivers. Thus adding this additional check is
> safe.
>
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian at intel.com>
More information about the Linuxppc-dev
mailing list