summaryrefslogtreecommitdiff
path: root/include/linux/workqueue_api.h
diff options
context:
space:
mode:
authorNicolin Chen <nicolinc@nvidia.com>2025-12-16 00:42:16 +0300
committerJoerg Roedel <joerg.roedel@amd.com>2026-01-10 12:26:42 +0300
commit5d5388b0e190b6decb964d3711473b7010bf1f6f (patch)
tree2358bbd327178821669039f7c8d7d7c70ff58738 /include/linux/workqueue_api.h
parent9ace4753a5202b02191d54e9fdf7f9e3d02b85eb (diff)
downloadlinux-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