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

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.