• D
    Push nwfilter update locking up to top level · 978648de
    Daniel P. Berrange 提交于
    The NWFilter code has as a deadlock race condition between
    the virNWFilter{Define,Undefine} APIs and starting of guest
    VMs due to mis-matched lock ordering.
    
    In the virNWFilter{Define,Undefine} codepaths the lock ordering
    is
    
      1. nwfilter driver lock
      2. virt driver lock
      3. nwfilter update lock
      4. domain object lock
    
    In the VM guest startup paths the lock ordering is
    
      1. virt driver lock
      2. domain object lock
      3. nwfilter update lock
    
    As can be seen the domain object and nwfilter update locks are
    not acquired in a consistent order.
    
    The fix used is to push the nwfilter update lock upto the top
    level resulting in a lock ordering for virNWFilter{Define,Undefine}
    of
    
      1. nwfilter driver lock
      2. nwfilter update lock
      3. virt driver lock
      4. domain object lock
    
    and VM start using
    
      1. nwfilter update lock
      2. virt driver lock
      3. domain object lock
    
    This has the effect of serializing VM startup once again, even if
    no nwfilters are applied to the guest. There is also the possibility
    of deadlock due to a call graph loop via virNWFilterInstantiate
    and virNWFilterInstantiateFilterLate.
    
    These two problems mean the lock must be turned into a read/write
    lock instead of a plain mutex at the same time. The lock is used to
    serialize changes to the "driver->nwfilters" hash, so the write lock
    only needs to be held by the define/undefine methods. All other
    methods can rely on a read lock which allows good concurrency.
    Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
    (cherry picked from commit 6e5c79a1)
    978648de
libvirt_private.syms 48.0 KB