This is more academic dispute than a real bug, but this is taken from pthread_cond_broadcast(3p) man: The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behavior is required, then that mutex shall be locked by the thread calling pthread_cond_broadcast() or pthread_cond_signal(). Therefore, broadcast the initCond while the nodedev driver is still locked. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> --- src/node_device/node_device_udev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 44f96f5ff9..20a13211a0 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1986,8 +1986,8 @@ nodeStateInitializeEnumerate(void *opaque) nodeDeviceLock(); driver->initialized = true; - nodeDeviceUnlock(); virCondBroadcast(&driver->initCond); + nodeDeviceUnlock(); return; -- 2.26.3