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@redhat.com>
---
 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

On Tue, Apr 13, 2021 at 12:01:54PM +0200, Michal Privoznik wrote:
> 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.

It is consistent with what we do elsewhere.

Reviewed-by: Erik Skultety <eskultet@redhat.com>