[libvirt] [PATCH 1/2] Revert fd066925440ba48acc95d8f31b2c98b1cc9d582d

Daniel P. Berrange berrange at redhat.com
Wed Dec 7 14:46:38 UTC 2011


From: "Daniel P. Berrange" <berrange at redhat.com>

Commit fd066925440ba48acc95d8f31b2c98b1cc9d582d tried to fix
a race condition in

  commit fa9595003d043df9f2efe95521c00898cef27106
  Author: Daniel P. Berrange <berrange at redhat.com>
  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




More information about the libvir-list mailing list