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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

    Stefan

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]