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.william...@redhat.com> >> Signed-off-by: Matthew Rosato <mjros...@linux.ibm.com> >> --- >> 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 <j...@nvidia.com> Thanks! > > Jason