[libvirt PATCH 3/5] qemu,lxc: remove use to nwfilter update lock

Daniel P. Berrangé berrange at redhat.com
Mon Feb 28 16:28:37 UTC 2022


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 :|




More information about the libvir-list mailing list