On 2/1/23 11:10 PM, Tian, Kevin wrote:
>> From: Alex Williamson
>> Sent: Thursday, February 2, 2023 7:28 AM
>>>
>>> +#ifdef CONFIG_HAVE_KVM
>>> +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm
>> *kvm)
>>
>> I'm tempted to name these vfio_device_get_kvm_safe() and only
> -Original Message-
> From: Alex Williamson
> Sent: Thursday, February 2, 2023 12:15 PM
> To: Liu, Yi L
> Cc: Matthew Rosato ; pbonz...@redhat.com;
> j...@nvidia.com; coh...@redhat.com; far...@linux.ibm.com;
> pmo...@linux.ibm.com; borntrae...@linux.ibm.com;
> fran...@linux.ibm.com;
On Thu, 2 Feb 2023 03:46:59 +
"Liu, Yi L" wrote:
> > From: Alex Williamson
> > Sent: Thursday, February 2, 2023 7:28 AM
> >
> > On Wed, 1 Feb 2023 14:20:10 -0500
> > Matthew Rosato wrote:
> >
> > > After 51cdc8bc120e, we have another deadlock scenario between the
> > > kvm->lock and
> From: Alex Williamson
> Sent: Thursday, February 2, 2023 7:28 AM
> >
> > +#ifdef CONFIG_HAVE_KVM
> > +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm
> *kvm)
>
> I'm tempted to name these vfio_device_get_kvm_safe() and only pass the
> vfio_device, where of course we
> From: Liu, Yi L
> Sent: Thursday, February 2, 2023 11:47 AM
> > > ret = vfio_device_open(device, device->group->iommufd,
> > > device->group->kvm);
> >
> > We're using device->group->kvm outside of kvm_ref_lock here, it should
> > be using device->kvm.
>
> Existing
> From: Alex Williamson
> Sent: Thursday, February 2, 2023 7:28 AM
>
> On Wed, 1 Feb 2023 14:20:10 -0500
> Matthew Rosato wrote:
>
> > After 51cdc8bc120e, we have another deadlock scenario between the
> > kvm->lock and the vfio group_lock with two different codepaths acquiring
> > the locks
On Wed, 1 Feb 2023 14:20:10 -0500
Matthew Rosato wrote:
> After 51cdc8bc120e, we have another deadlock scenario between the
> kvm->lock and the vfio group_lock with two different codepaths acquiring
> the locks in different order. Specifically in vfio_open_device, vfio
> holds the vfio
After 51cdc8bc120e, we have another deadlock scenario between the
kvm->lock and the vfio group_lock with two different codepaths acquiring
the locks in different order. Specifically in vfio_open_device, vfio
holds the vfio group_lock when issuing device->ops->open_device but some
drivers (like
