[libvirt] [PATCH 3/5] Push nwfilter update locking up to top level

Daniel P. Berrange berrange at redhat.com
Mon Jan 27 18:10:37 UTC 2014

On Mon, Jan 27, 2014 at 01:05:51PM -0500, Stefan Berger wrote:
> On 01/27/2014 12:15 PM, Daniel P. Berrange wrote:
> >On Thu, Jan 23, 2014 at 04:13:57PM -0500, Stefan Berger wrote:
> >>This function here is called by
> >>src/nwfilter/nwfilter_learnip.c::learnIPAddressThread
> >>src/nwfilter/nwfilter_dhcpsnoop.c::virNWFilterSnoopIPLeaseInstallRule
> >>
> >>They instantiate the filters once a VM's IP address has been
> >>detected. So this is where the *Late() comes from.
> >>
> >>If you remove the locking from here, you have to lock it there.
> >>Considering what you do layer, I would keep the lock here and
> >>convert this into a reader lock layer on.
> >Yes, now I'm squashing the read/write lock conversion in, I'll
> >keep the locking in this location.
> Is there interest in introducing an assert() in those functions
> expecting a lock to be held? I know it's not as simple as just
> putting an assert() into the code. Actually we would have to record
> in an array or linked list the threads holding a lock and provide a
> function to check whether pthread_self() is holding the lock. The
> latter function would be called by an assert(). I would give it a
> shot by introducing a boolean as parameter to the lock init function
> that activates the recording of which threads are currently holding
> a lock -- if this is thought to be useful.

Usage of assert() is forbiddenn in any libvirt code, and the complexity
of tracking threads this really not something I'd want to persue.

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

More information about the libvir-list mailing list