On Mon, Feb 28, 2022 at 11:24:07AM -0500, Laine Stump wrote: > On 2/25/22 10:30 AM, Daniel P. Berrangé wrote: > > Now that the virNWFilterBinding APIs are using the nwfilter > > update lock directly, there is no need for the virt drivers > > to do it themselves. > > I'm always nervous when the ordering of locks is changed, and that's what is > happening with the combination of this patch and the previous patch. Before > it was always the NWFilterLock that was acquired first, and then the domain > object is retrieved (which involves getting the domain-list lock while > getting a ref to the domain object). > > But since holding of the domain-list lock is localized to that short period > (and certainly never across a call to the NWFilter binding API) I'm fairly > certain this (along with the previous patch) is safe from creating any new > deadlocks. Note the reason for that ordering was that in the past the nwfilter driver would have ability to call back into the virt driver to ask the virt driver to reload all nwfilters for VMs. With this callback we would acquire the nwfilter update lock, and then iterate over each VM in turn. The nwfilter driver no longer has this ability. It is completely self contained when re-loadeding nwfilters. The only calls are from the virt driver into the nwfilter driver. Thus there can never be any scenario where a nwfilter driver lock is held when the virt driver tries to acquire a domain lock. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
