On Mon, Jul 26, 2021 at 07:03:17PM -0300, Jason Gunthorpe wrote: > On Mon, Jul 26, 2021 at 10:36:28PM +0200, Halil Pasic wrote: > > > You may end up with open and close running interleaved. What I' > > trying to say is, to my best knowledge, normally there is no > > you have to close it before you open it again rule for files. > > This is an existing bug in this driver, I've fixed in the reflck series. > > open_device/close_device will not run concurrently, or out of order, > afer it is fixed. Btw, while I've got all your attention, I've been struggling a bit with how that SET_KVM notifier is supposed to work. The i915 gvt code simplify assumes the notification registration hits the case of KVM already being active, and gets away with that as at least qemu ensures that the KVM_DEV_VFIO_GROUP_ADD has been called before the device FDs are opened. Is that something we could generalize and never allow to actually notify for SET_KVM with non-null data beeing called at runtime and avoid the locking entirely? Similarly the removal case is a little weird: with Jason's work to only call a release function on the last reference drop which solves a lot of concurrency issues nicely this still creates a nasty corner case with a sideband release under weird locking rules. What prevents the vfio core from simply holding a refefeence to the struct kvm as long as the device is open to close that hole?
