Re: [PATCH 09/10] iommu: Complete the locking for dev->iommu_group

On 2023/7/19 3:05, Jason Gunthorpe wrote:

Revise the locking for dev->iommu_group so that it has three safe ways to
access it:

  - It is read by a probe'd device driver. So long as a device driver is
    probed the dev->iommu_group will be guaranteed stable without further
    locking.

  - Read under the device_lock(), this primarily protects against
    parallel probe of the same device, and parallel probe/remove

  - Read/Write under the global dev_iommu_group_lock. This is used during
    probe time discovery of groups. Device drivers will scan unlocked
    portions of the device tree to locate an already existing group. These
    scans can access the dev->iommu_group under the global lock to single
    thread determining and installing the group. This ensures that groups
    are reliably formed.

Narrow the scope of the global dev_iommu_group_lock to be only during the
dev->iommu_group setup, and not for the entire probing.

Prior patches removed the various races inherent to the probe process by
consolidating all the work under the group->mutex. In this configuration
it is fine if two devices race to the group_device step of a new
iommu_group, the group->mutex locking will ensure the group_device and
domain setup part remains properly ordered.

Add the missing locking on the remove paths. For iommu_deinit_device() it
is necessary to hold the dev_iommu_group_lock due to possible races during
probe error unwind.

Fully lock the iommu_group_add/remove_device() path so we can use lockdep
assertions. Other than lockdep this is redundant, VFIO no-iommu doesn't
use group clustering.

For iommu_release_device() it is redundant, as we expect no external
references to the struct device by this point, but it is harmless so
add the missing lock to allow lockdep assertions to work.

This resolves the remarks of the comment in __iommu_probe_device().

Signed-off-by: Jason Gunthorpe<jgg@nvidia.com>

Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>

Best regards,
baolu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel