]> xenbits.xensource.com Git - libvirt.git/commit
processSerialChangedEvent: Close agent monitor early
authorMichal Privoznik <mprivozn@redhat.com>
Thu, 7 May 2015 09:19:38 +0000 (11:19 +0200)
committerMichal Privoznik <mprivozn@redhat.com>
Thu, 7 May 2015 09:31:17 +0000 (11:31 +0200)
commit2af51483cc2fa43b70b41b4aaa88eeb77701f590
treee9793a06133afef794050c8aae69b336f6b63f51
parent21e8fc36c6e74120fb9edfcd5d15b13bbf365263
processSerialChangedEvent: Close agent monitor early

https://bugzilla.redhat.com/show_bug.cgi?id=890648

So, imagine you've issued an API that involves guest agent. For
instance, you want to query guest's IP addresses. So the API acquires
QUERY_JOB, locks the guest agent and issues the agent command.
However, for some reason, guest agent replies to initial ping
correctly, but then crashes tragically while executing real command
(in this case guest-network-get-interfaces). Since initial ping went
well, libvirt thinks guest agent is accessible and awaits reply to the
real command. But it will never come. What will is a monitor event.
Our handler (processSerialChangedEvent) will try to acquire
MODIFY_JOB, which will fail obviously because the other thread that's
executing the API already holds a job. So the event handler exits
early, and the QUERY_JOB is never released nor ended.

The way how to solve this is to put flag somewhere in the monitor
internals. The flag is called @running and agent commands are issued
iff the flag is set. The flag itself is set when we connect to the
agent socket. And unset whenever we see DISCONNECT event from the
agent. Moreover, we must wake up all the threads waiting for the
agent. This is done by signalizing the condition they're waiting on.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
src/qemu/qemu_agent.c
src/qemu/qemu_agent.h
src/qemu/qemu_driver.c