On 2022/6/21 11:26, Tian, Kevin wrote:
From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
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
