]> xenbits.xensource.com Git - libvirt.git/commit
libxl: find virDomainObj in libxlDomainShutdownThread
authorJim Fehlig <jfehlig@suse.com>
Wed, 21 Sep 2016 21:02:34 +0000 (15:02 -0600)
committerJim Fehlig <jfehlig@suse.com>
Tue, 27 Sep 2016 15:14:10 +0000 (09:14 -0600)
commit7b3cf84bbb4d54c519ab1fae8f711105f60d61bd
tree12974dfcb3740b138e8f67d65aa3b85bffb10a3a
parent934c4dbea85e8eac5dfd50b51283d34dbaa6e476
libxl: find virDomainObj in libxlDomainShutdownThread

libxl events are delivered to libvirt via the libxlDomainEventHandler
callback registered with libxl. Documenation in
$xensrc/tools/libxl/libxl_event.h states that the callback "may occur
on any thread in which the application calls libxl". This can result
in deadlock since many of the libvirt callees of libxl hold a lock on
the virDomainObj they are working on. When the callback is invoked, it
attempts to find a virDomainObj corresponding to the domain ID provided
by libxl. Searching the domain obj list results in locking each obj
before checking if it is active, and its ID equals the requested ID.
Deadlock is possible when attempting to lock an obj that is already
locked further up the call stack. Indeed, Max Ustermann reported an
instance of this deadlock

https://www.redhat.com/archives/libvir-list/2015-November/msg00130.html

Guido Rossmueller also recently stumbled across it

https://www.redhat.com/archives/libvir-list/2016-September/msg00287.html

Fix the deadlock by moving the lookup of virDomainObj to the
libxlDomainShutdownThread. After this patch, libxl events are
enqueued on the libvirt side and processed by dedicated thread,
avoiding the described deadlock.

Reported-by: Max Ustermann <ustermann78@web.de>
Reported-by: Guido Rossmueller <Guido.Rossmueller@gdata.de>
src/libxl/libxl_domain.c