On 03/26/2013 09:52 AM, Jiri Denemark wrote:
Despite of the comment stating virNetClientIncomingEvent handler
should
s/of //
never be called with either client->haveTheBuck or
client->wantClose
set, there is a sequence of events that may lead to both booleans being
true when virNetClientIncomingEvent is called. However, when that
happens, we must not immediately close the socket as there are other
threads waiting for the buck and they would cause SIGSEGV once they are
woken up after the socket was closed. Another thing is we should clear
all remaining calls in the queue after closing the socket.
The situation that can lead to the crash involves three threads, one of
them running event loop and the other two calling libvirt APIs. The
event loop threads detects an event on client->sock and calls
virNetClientIncomingEvent handler. But before the handler gets a chance
to lock client, the other two threads (T1 and T2) start calling some
APIs. T1 gets the buck and detects EOF on client->sock while processing
its RPC call. Since T2 is waiting for its own call, T1 passes the buck
onto it and unlocks client. But before T2 gets the signal, the event
s/onto/on to/
loop thread wakes up, does its job and closes client->sock. The
crash
happens when T2 actually wakes up and tries to do its job using a closed
client->sock.
---
src/rpc/virnetclient.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Tricky analysis, but I agree with the outcome. Definitely worth fixing
in 1.0.4.
ACK.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org