[libvirt] [PATCH 1/2] Revert fd066925440ba48acc95d8f31b2c98b1cc9d582d

From: "Daniel P. Berrange" <berrange(a)redhat.com&gt; Commit fd066925440ba48acc95d8f31b2c98b1cc9d582d tried to fix a race condition in commit fa9595003d043df9f2efe95521c00898cef27106 Author: Daniel P. Berrange <berrange(a)redhat.com&gt; Date: Fri Nov 11 15:28:41 2011 +0000 Explicitly track whether the buck is held in remote client Unfortunately there is a second race condition whereby the event loop can trigger due to incoming data to read. Revert this fix, so a complete fix for the problem can be cleanly applied * src/rpc/virnetclient.c: Revert fd066925440ba48acc95d8f31b2c98b1cc9d582d --- src/rpc/virnetclient.c | 9 +-------- 1 files changed, 1 insertions(+), 8 deletions(-) diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c index 7f9a332..e35521d 100644 --- a/src/rpc/virnetclient.c +++ b/src/rpc/virnetclient.c @@ -1545,7 +1545,6 @@ static int virNetClientIO(virNetClientPtr client, virNetClientCallQueue(&client->waitDispatch, thiscall); /* Check to see if another thread is dispatching */ -recheck: if (client->haveTheBuck) { char ignore = 1; @@ -1593,13 +1592,7 @@ recheck: goto cleanup; } - /* Grr, someone might have passed the buck onto us ... */ - - /* We need to re-check if the buck has been passed to this thread - * as this thread might have been signalled to wake up, but another - * call might acquire the lock before this thread manages to wake up. - * This could cause that two threads claim they have the buck */ - goto recheck; + /* Grr, someone passed the buck onto us ... */ } VIR_DEBUG("We have the buck %p %p", client->waitDispatch, thiscall); -- 1.7.7.3