- domain_remove_one_dev_info() starts by taking device_domain_lock then takes iommu->lock inside it (near the end of the function).

So this is the classic AB-BA deadlock. It looks like a safe fix is tosimply release device_domain_lock a bit earlier, since as far as I cantell, it doesn't protect any of the stuff accessed at the end ofdomain_remove_one_dev_info() anyway.

BTW, the use of device_domain_lock looks a bit unsafe to me... it'sat least not obvious to me why we aren't vulnerable to the race below:

iommu_support_dev_iotlb() domain_remove_dev_info()

lock device_domain_lock find info unlock device_domain_lock

lock device_domain_lock find same info unlock device_domain_lock

free_devinfo_mem(info)

do stuff with info after it's free

However I don't understand the locking here well enough to know ifthis is a real problem, let alone what the best fix is.