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
