> 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.
