[Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock

Matthew Rosato mjrosato at linux.ibm.com
Wed Feb 1 14:27:45 UTC 2023


On 2/1/23 1:13 AM, Tian, Kevin wrote:
>> From: Matthew Rosato <mjrosato at linux.ibm.com>
>> Sent: Wednesday, February 1, 2023 4:07 AM
>>
>> -	device->kvm = kvm;
>> +	/*
>> +	 * Get the KVM pointer currently associated with the group, if there
>> +	 * is one, and obtain a reference now that will be held until the
>> +	 * open_count reaches 0.  Save the pointer in the device for use by
>> +	 * drivers.
>> +	 */
>> +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
>> +	if (group->kvm && vfio_kvm_get_kvm_safe(device, group->kvm))
>> +		device->kvm = group->kvm;
>> +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
>> +
> 
> No group reference in vfio_main.c. 

OK -- I think to do that I'll have to move the lock/unlock of the dev_set lock to group.c right before we call vfio_device_{open,close} and check open_count there to make decisions about the kvm ref (before calling vfio_device_open to decide to get kvm ref, after returning from vfio_device_open to see if we to drop ref on error, after close to see if we need to drop ref).

> 
> btw Yi, looks the deadlock issue also exists in your cdev work.
> 
> kvm_vfio_release() holds kvm lock and then try to acquire
> device->device_set->lock in vfio_device_file_set_kvm().
> 
> vfio_device_ioctl_bind_iommufd() holds device->device_set->lock
> and then call vfio_device_open() which finally hit kvm lock
> acquisition in driver's open_device routine (e.g. vfio-ap).
> 
> A similar fix is required in your series.
> 
> Thanks
> Kevin



More information about the Intel-gfx mailing list