[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