On Tue, Feb 16, 2016 at 15:37:00 +0100, Jiri Denemark wrote: > Calling qemuProcessStop without a job opens a way to race conditions > with qemuDomainObjExitMonitor called in another thread. A real world > example of such a race condition: > > - migration thread (A) calls qemuMigrationWaitForSpice > - another thread (B) starts processing qemuDomainAbortJob API > - thread B signals thread A via qemuDomainObjAbortAsyncJob > - thread B enters monitor (qemuDomainObjEnterMonitor) > - thread B calls qemuMonitorSend > - thread A awakens and calls qemuProcessStop > - thread A calls qemuMonitorClose and sets priv->mon to NULL > - thread B calls qemuDomainObjExitMonitor with priv->mon == NULL > => monitor stays ref'ed and locked > > Depending on how lucky we are, the race may result in a memory leak or > it can even deadlock libvirtd's event loop if it tries to lock the > monitor to process an event received before qemuMonitorClose was called. > > Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> > --- > src/qemu/qemu_driver.c | 28 +++++++++++------- > src/qemu/qemu_migration.c | 6 +++- > src/qemu/qemu_process.c | 72 +++++++++++++++++++++++++++++++---------------- > src/qemu/qemu_process.h | 1 + > 4 files changed, 71 insertions(+), 36 deletions(-) ACK
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list