On 03/03/2011 12:47 PM, Laine Stump wrote: > This was also found while investigating > > https://bugzilla.redhat.com/show_bug.cgi?id=670848 > > An EOF on a domain's monitor socket results in an event being queued > to handle the EOF. The handler calls qemuProcessHandleMonitorEOF. If > it is a transient domain, this leads to a call to > virDomainRemoveInactive, which removes the domain from the driver's > hashtable and unref's it. Nowhere in this code is the qemu driver lock > acquired. > > However, all modifications to the driver's domain hashtable *must* be > done while holding the driver lock, otherwise the hashtable can become > corrupt, and (even more likely) another thread could call a different > hashtable function and acquire a pointer to the domain that is in the > process of being destroyed. > > To prevent such a disaster, qemuProcessHandleMonitorEOF must get the > qemu driver lock *before* it gets the DomainObj's lock, and hold it > until it is finished with the DomainObj. This guarantees that nobody > else modifies the hashtable at the same time, and that anyone who had > already gotten the DomainObj from the hashtable prior to this call has > finished with it before we remove/destroy it. > --- > src/qemu/qemu_process.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) Makes sense to me, given src/qemu/THREADS.txt, but you may want to wait for danpb's ACK as well. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list