diff options
| author | Nicolin Chen <nicolinc@nvidia.com> | 2025-12-16 00:42:16 +0300 |
|---|---|---|
| committer | Joerg Roedel <joerg.roedel@amd.com> | 2026-01-10 12:26:42 +0300 |
| commit | 5d5388b0e190b6decb964d3711473b7010bf1f6f (patch) | |
| tree | 2358bbd327178821669039f7c8d7d7c70ff58738 /include/linux/workqueue_api.h | |
| parent | 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb (diff) | |
| download | linux-5d5388b0e190b6decb964d3711473b7010bf1f6f.tar.xz | |
iommu: Lock group->mutex in iommu_deferred_attach()
The iommu_deferred_attach() function invokes __iommu_attach_device(), but
doesn't hold the group->mutex like other __iommu_attach_device() callers.
Though there is no pratical bug being triggered so far, it would be better
to apply the same locking to this __iommu_attach_device(), since the IOMMU
drivers nowaday are more aware of the group->mutex -- some of them use the
iommu_group_mutex_assert() function that could be potentially in the path
of an attach_dev callback function invoked by the __iommu_attach_device().
Worth mentioning that the iommu_deferred_attach() will soon need to check
group->resetting_domain that must be locked also.
Thus, grab the mutex to guard __iommu_attach_device() like other callers.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Tested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Diffstat (limited to 'include/linux/workqueue_api.h')
0 files changed, 0 insertions, 0 deletions
