From f5b37c4f1768df3464a7666255975f7c7f2d14b3 Mon Sep 17 00:00:00 2001 From: Michal Privoznik Date: Tue, 13 Apr 2021 10:52:07 +0200 Subject: [PATCH 059/108] nodedev: Signal initCond with driver locked 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 Reviewed-by: Erik Skultety (cherry picked from commit 5b56a288cab097896832dc9d4acb7f23dfca377c) --- 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 a1391fb0de..000494f9e3 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1749,8 +1749,8 @@ nodeStateInitializeEnumerate(void *opaque) nodeDeviceLock(); driver->initialized = true; - nodeDeviceUnlock(); virCondBroadcast(&driver->initCond); + nodeDeviceUnlock(); return; -- 2.33.0