It may happen that qemuProcessStop() is called from "qemu-event"
thread. But this thread doesn't have any virIdentity set
(virIdentity being thread local) and therefore it may be unable
to open connection to secondary drivers. It is unable to do so
in split daemon scenario, because in there opening a connection
is coupled with copying current thread identity onto the
connection. Code-wise, virIdentityGetCurrent() returns NULL which
in turn makes virGetConnectGeneric() fail. This problem does not
occur in monolithic daemon scenario, because no identity copying
is done there.
Long story short, inability to open secondary driver connection
can lead to unwanted results. Therefore, do what
qemuProcessReconnectHelper() does - set the new thread identity
to be the one of the caller.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=2013573
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_driver.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index a8bf0ecc6f..70b5f37e6b 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -571,6 +571,7 @@ qemuStateInitialize(bool privileged,
size_t i;
const char *defsecmodel = NULL;
g_autofree virSecurityManager **sec_managers = NULL;
+ g_autoptr(virIdentity) identity = virIdentityGetCurrent();
qemu_driver = g_new0(virQEMUDriver, 1);
@@ -915,7 +916,7 @@ qemuStateInitialize(bool privileged,
* events that will be dispatched to the worker pool */
qemu_driver->workerPool = virThreadPoolNewFull(0, 1, 0, qemuProcessEventHandler,
"qemu-event",
- NULL,
+ identity,
qemu_driver);
if (!qemu_driver->workerPool)
goto error;
--
2.32.0