Files
computing-offload/generic_vdpa/libvirt/nodedev-Signal-initCond-with-driver-locked.patch
jiangdongxu 79c4324644 add generic_vdpa basecode
Change-Id: I2d302dda68298877c65c99147f5bf22186a59aac
2024-09-19 17:19:46 +08:00

45 lines
1.5 KiB
Diff

From f5b37c4f1768df3464a7666255975f7c7f2d14b3 Mon Sep 17 00:00:00 2001
From: Michal Privoznik <mprivozn@redhat.com>
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 <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
(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