On Fri, Jan 13, 2023 at 03:09:01PM -0500, Matthew Rosato wrote: > > This still doesn't seem right, another thread could have incr'd the > > open_count already > > > > This has to be done at the moment open_count is decremented to zero, > > while still under the original lock. > > Hmm.. Fair. Well, we can go back to clearing of device->kvm in > vfio_device_last_close but the group lock is held then so we can't > immediately do the kvm_put at that time -- unless we go back to the > notion of stacking the kvm_put on a workqueue, but now from vfio. > If we do that, I think we also have to scrap the idea of putting the > kvm_put_kvm function pointer into device->put_kvm too (or otherwise > stash it along with the kvm value to be picked up by the scheduled > work). Well, you have to keep the same sort of design, the vfio_device_last_close() has to put the kvm on the stack until the group lock is unlocked. It is messy due to how the functions are nested, but not hard. Jason
