On 1/9/23 3:13 PM, Jason Gunthorpe wrote:
> On Mon, Jan 09, 2023 at 03:10:36PM -0500, Matthew Rosato wrote:
>> Currently it is possible that the final put of a KVM reference comes from
>> vfio during its device close operation. This occurs while the vfio group
>> lock is held; however, if the vfio device is still in the kvm device list,
>> then the following call chain could result in a deadlock:
>>
>> kvm_put_kvm
>> -> kvm_destroy_vm
>> -> kvm_destroy_devices
>> -> kvm_vfio_destroy
>> -> kvm_vfio_file_set_kvm
>> -> vfio_file_set_kvm
>> -> group->group_lock/group_rwsem
>>
>> Avoid this scenario by adding kvm_put_kvm_async which will perform the
>> kvm_destroy_vm asynchronously if the refcount reaches 0.
>>
>> Fixes: 421cfe6596f6 ("vfio: remove VFIO_GROUP_NOTIFY_SET_KVM")
>> Reported-by: Alex Williamson <alex.williamson@xxxxxxxxxx>
>> Signed-off-by: Matthew Rosato <mjrosato@xxxxxxxxxxxxx>
>> ---
>> drivers/gpu/drm/i915/gvt/kvmgt.c | 6 +++++-
>> drivers/s390/crypto/vfio_ap_ops.c | 7 ++++++-
>> include/linux/kvm_host.h | 3 +++
>> virt/kvm/kvm_main.c | 22 ++++++++++++++++++++++
>> 4 files changed, 36 insertions(+), 2 deletions(-)
>
> Why two patches?
>
> It looks OK to me
Mentioned in the cover, the fixes: tag is different on the 2nd patch as the s390 PCI passthrough kvm_puts were added later soemtime after 421cfe6596f6 ("vfio: remove VFIO_GROUP_NOTIFY_SET_KVM"). The blamed commit for those changes also landed in a different release (6.0 vs 5.19).
But, now that you mention it, neither is an LTS so it probably doesn't matter all that much and could be squashed if preferred.
>
> Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
Thanks!
>
> Jason
