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