Messages in this thread | | | Date | Wed, 7 Dec 2022 14:18:36 +0000 | Subject | Re: [PATCH v2 4/7] iommu: Let iommu.strict override ops->def_domain_type | From | Robin Murphy <> |
| |
On 2022-12-07 13:23, Jason Gunthorpe wrote: > On Wed, Dec 07, 2022 at 09:18:19PM +0800, Baolu Lu wrote: > >>> - /* Check if the device in the group still has a driver bound to it */ >>> - device_lock(dev); >> >> With device_lock() removed, this probably races with the >> iommu_release_device() path? group->mutex seems insufficient to avoid >> the race. Perhaps I missed anything. > > This path only deals with group, so there is no 'dev' and no race with > removal.
If we can now use the ownership mechanism to enforce the required constraints for change_dev_def_domain, that would be worthwhile (and a lot clearer) as a separate patch in its own right.
Thanks, Robin.
> Later on we obtain the group mutex and then extract the first device > from the group list as a representative device of the group - eg to > perform iommu_domain allocation. > > Under the group mutex devices on the device list cannot become > invalid. > > It is the same reasoning we use in other places that iterate over the > group device list under lock. > > Jason
| |