> From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
> Sent: Tuesday, June 21, 2022 9:32 AM
>
> On 2022/6/21 04:13, Matthew Rosato wrote:
> > On 6/20/22 4:54 AM, Yi Liu wrote:
> >> No need to protect open_count with group_rwsem
> >>
> >> Fixes: 421cfe6596f6 ("vfio: remove VFIO_GROUP_NOTIFY_SET_KVM")
> >>
> >> cc: Matthew Rosato <mjrosato@xxxxxxxxxxxxx>
> >> cc: Jason Gunthorpe <jgg@xxxxxxxxxx>
> >> Signed-off-by: Yi Liu <yi.l.liu@xxxxxxxxx>
> >
> > Seems pretty harmless as-is, but you are correct group_rwsem can be
> dropped
> > earlier; we do not protect the count with group_rwsem elsewhere (see
> > vfio_device_fops_release as a comparison, where we already drop
> group_rwsem
> > before open_count--)
>
> yes. this is exactly how I found it. Normally, I compare the err handling
> path with the release function to see if they are aligned. :-)
In this case we don't need a FIX tag. It's kind of optimization.
>
> > 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.
