On Tue, Mar 26, 2013 at 10:17:01 -0600, Eric Blake wrote:
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.
Thanks, I fixed one more typo in the commit message and pushed.
Jirka