On 1/5/23 7:32 PM, Jason Gunthorpe wrote: > On Thu, Jan 05, 2023 at 07:16:37PM -0500, Matthew Rosato wrote: > >> Yeah, this is also what I was thinking, replace the direct >> kvm_put_kvm calls with, say, schedule_delayed_work in each driver, >> where the delayed task just does the kvm_put_kvm (along with a brief >> comment explaining why we handle the put asynchronously). > > Don't put that in every driver, do something like mmput_async() where > the core code has all of this. > If the core vfio code were to add logic to invoke kvm_put_kvm and kvm_get_kvm, won't this introduce a vfio dependency on kvm? If I recall, we have the drivers handling the kvm reference today in order to avoid that.. >> Other than that.. The goal of this patch originally was to get the >> kvm reference at first open_device and release it with the very last >> close_device, so the only other option I could think of would be to >> take the responsibility back from the vfio drivers and do the >> kvm_get_kvm and kvm_put_kvm directly in vfio_main after dropping the >> (but that would result in some ugly symbol linkage and would acquire >> kvm references that a driver maybe does not care about so I don't >> really like that idea) > > And we still have the deadlock problem anyhow.. Looks like I never finished my sentence here -- I meant call kvm_put_kvm directly in vfio_main after dropping the group lock (e.g. when we set device->kvm = NULL;). But I think we'd still have the kvm dependency issue
