All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yi Liu <yi.l.liu@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"jgg@nvidia.com" <jgg@nvidia.com>
Subject: Re: [Patch 1/1] vfio: Move "device->open_count--" out of group_rwsem in vfio_device_open()
Date: Tue, 21 Jun 2022 11:35:35 +0800	[thread overview]
Message-ID: <4569fe37-f72f-631d-9cfb-7451810c65b0@intel.com> (raw)
In-Reply-To: <BN9PR11MB5276887FCA896E53829300F38CB39@BN9PR11MB5276.namprd11.prod.outlook.com>

On 2022/6/21 11:26, Tian, Kevin wrote:
>> From: Liu, Yi L <yi.l.liu@intel.com>
>> Sent: Tuesday, June 21, 2022 10:59 AM
>>>>
>>>>> FWIW, this change now also drops group_rswem before setting device-
>>>>> kvm =
>>>>> NULL, but that's also OK (again, just like vfio_device_fops_release) --
>>>>> While the setting of device->kvm before open_device is technically done
>>>>> while holding the group_rwsem, this is done to protect the group kvm
>>>> value
>>>>> we are copying from, and we should not be relying on that to protect the
>>>>> contents of device->kvm; instead we assume this value will not change
>> until
>>>>> after the device is closed and while under the dev_set->lock.
>>>>
>>>> yes. set device->kvm to be NULL has no need to hold group_rwsem. BTW.
>> I
>>>> also doubt whether the device->ops->open_device(device) and
>>>> device->ops->close_device(device) should be protected by group_rwsem
>> or
>>>> not. seems not, right? group_rwsem protects the fields under vfio_group.
>>>> For the open_device/close_device() device->dev_set->lock is enough.
>> Maybe
>>>> another nit fix.
>>>>
>>>
>>> group->rwsem is to protect device->group->kvm from being changed
>>> by vfio_file_set_kvm() before it is copied to device->kvm.
>>
>> yes. this is why vfio_device_open() holds the read lock of group_rwsem
>> around the device->group->kvm copy. However, for the open_device(),
>> callback, I don't think it is necessary to be protected by the group_rwsem
>> lock.
>>
> 
> The kvm object could be freed after device->kvm is set, if
> group_rwsem is not held when calling open_device(). Then you'll
> hit another use-after-free bug when mdev driver tries to obtain
> a reference on kvm.

aha. I see. so group_rwsem prevents the kvm object free as such a thread
should be blocked in the vfio_file_set_kvm() if the vfio_device_open() has
held the group_rwsem. Hence kvm object is safe to be used. thanks!

-- 
Regards,
Yi Liu

  reply	other threads:[~2022-06-21  3:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20  8:54 [Patch 0/1] A bug fix to the error handling path in vfio_device_open() Yi Liu
2022-06-20  8:54 ` [Patch 1/1] vfio: Move "device->open_count--" out of group_rwsem " Yi Liu
2022-06-20 20:13   ` Matthew Rosato
2022-06-21  1:31     ` Yi Liu
2022-06-21  2:49       ` Tian, Kevin
2022-06-21  2:59         ` Yi Liu
2022-06-21  3:26           ` Tian, Kevin
2022-06-21  3:35             ` Yi Liu [this message]
2022-06-24 14:05   ` Jason Gunthorpe
2022-06-27  7:45     ` Yi Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4569fe37-f72f-631d-9cfb-7451810c65b0@intel.com \
    --to=yi.l.liu@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.