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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list