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

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



On Wed, Oct 06, 2010 at 05:56:36PM -0400, Stefan Berger wrote:
>  V2:
>   remove the locks from qemudVMFilterRebuild & umlVMFilterRebuild
> 
>  This is from a bug report and conversation on IRC where Soren reported 
> that while a filter update is occurring on one or more VMs (due to a 
> rule having been edited for example), a deadlock can occur when a VM 
> referencing a filter is started.
> 
> The problem is caused by the two locking sequences of
> 
> qemu driver, qemu domain, filter             # for the VM start operation
> filter, qemu_driver, qemu_domain            # for the filter update 
> operation
> 
> that obviously don't lock in the same order. The problem is the 2nd lock 
> sequence. Here the qemu_driver lock is being grabbed in 
> qemu_driver:qemudVMFilterRebuild()
> 
> The following solution is based on the idea of trying to re-arrange the 
> 2nd sequence of locks as follows:
> 
> qemu_driver, filter, qemu_driver, qemu_domain
> 
> and making the qemu driver recursively lockable so that a second lock 
> can occur, this would then lead to the following net-locking sequence
> 
> qemu_driver, filter, qemu_domain
> 
> where the 2nd qemu_driver lock has been ( logically ) eliminated.
> 
> The 2nd part of the idea is that the sequence of locks (filter, 
> qemu_domain) and (qemu_domain, filter) becomes interchangeable if all 
> code paths where filter AND qemu_domain are locked have a preceding 
> qemu_domain lock that basically blocks their concurrent execution

I'm not entirely happy with this locking scheme, because the
broken lock ordering problem is still present. We're just 
relying on the fact that we retain the global lock to protect
us against the ongoing lock ordering issue.

That said, I don't see any immediately obvious alternative
to solve this problem. So I guess I'll ack this approach
for now. One day this will likely need re-visiting...

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


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