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

[Daniel Veillard]

On Thu, Oct 07, 2010 at 10:06:55AM -0400, Stefan Berger wrote:
>  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.

 sure, it was an RFC :-)

> >>+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.

  That would be nice, yes

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/