[libvirt] [PATCH] [RFC] nwfilter: resolve deadlock between VM operations and filter update

[Stefan Berger]

  On 10/07/2010 09:52 AM, Daniel Veillard wrote:
> On Wed, Oct 06, 2010 at 05:56:36PM -0400, Stefan Berger wrote:
>>   V2:
>>    remove the locks from qemudVMFilterRebuild&  umlVMFilterRebuild
>
>> For now I want to put this out as an RFC patch. I have tested it by
>> 'stretching' the critical section after the define/undefine
>> functions each lock the filter so I can (easily) concurrently
>> execute another VM operation (suspend,start). That code is in this
>> patch and if you want you can de-activate it. It seems to work ok
>> and operations are being blocked while the update is being done.
>> I still also want to verify the other assumption above that locking
>> filter and qemu_domain always has a preceding qemu_driver lock.
>    I looked at the patch and the only thing that need to be cleaned up
> is the stretching blocki below, otherwise looks fine to me.
>
Yes, I'll remove that.
>> +if (true) {
>> +    fprintf(stderr,"sleep in %s\n", __FUNCTION__);
>> +    sleep(CRITICAL_SECTION_STRETCH);
>> +    fprintf(stderr,"continue in %s\n", __FUNCTION__);
>> +}
>> +
>    It would be good to have some ways to exercise all code paths
> in the locking (okay error handling specific paths aside because
> it's really hard), before applying.
>
It will take some time, but I'll try to write a TCK test that does 
something like Soren was testing:

- concurrently create/destroy 2 vms
- concurrently modify their filters
- plus occasionally shoot a SIGHUP at libvirt ( if possible )

That would test some of the code paths.

   Stefan