From: Weilun Zhu <zhuweilun@xxxxxxxxxx>
As qemuMonitorJSONIOProcess() will unlock the qemu monitor, there is
some extreme situation, eg qemu send message to monitor twice in a short
time, where the local viriable 'msg' of qemuMonitorIOProcess() could be
a wild point:
1. qemuMonitorSend() assign mon->msg to parameter 'msg', which is alse a
local variable of its caller qemuMonitorJSONCommandWithFd(), cause
eventloop to send message to monitor, then wait condition.
2. qemu send message to monitor for the first time immediately.
3. qemuMonitorIOProcess() is called, then wake up the qemuMonitorSend()
thread, but the qemuMonitorSend() thread stuck for a while, which means
the qemu monitor is still unlocked.
4. qemu send message to monitor for the second time, such as RTC_CHANGE
event
5. qemuMonitorIOProcess() is called, the local viriable 'msg' is
assigned to mon->msg.
6. qemuMonitorIOProcess() call qemuMonitorJSONIOProcess() to deal with
the message
7. qemuMonitorJSONIOProcess() unlock the qemu monitor, qemuMonitorSend()
thread get the lock and free the mon->msg, assign mon->msg to NULL.
so the local viriable 'msg' of qemuMonitorIOProcess() is a wild pointer
now.
AFAIK, it is not harmful to call again virCondBroadcast() while msg is a
wild pointer, but just in case, we fix it in this patch.
---
src/qemu/qemu_monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 43f1d2f..464f200 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -454,7 +454,7 @@ qemuMonitorIOProcess(qemuMonitorPtr mon)
#if DEBUG_IO
VIR_DEBUG("Process done %d used %d", (int)mon->bufferOffset, len);
#endif
- if (msg && msg->finished)
+ if (msg && msg == mon->msg && msg->finished)
virCondBroadcast(&mon->notify);
return len;
}
--
1.8.3.1
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
