[SCM] Samba Shared Repository - branch v3-0-test updated - release-3-0-32-98-g8904b83

[Jeremy Allison]

The branch, v3-0-test has been updated
       via  8904b83ce6c69db31dc2ce4c05e8e8ee3db5ec3b (commit)
      from  3ee41667d7bb8358c80af24f78dbdd071fa9c765 (commit)

http://gitweb.samba.org/?p=samba.git;a=shortlog;h=v3-0-test


- Log -----------------------------------------------------------------
commit 8904b83ce6c69db31dc2ce4c05e8e8ee3db5ec3b
Author: Jeremy Allison <jra at samba.org>
Date:   Thu Jan 8 10:56:36 2009 -0800

    Fix race condition in alarm lock processing noticed by Richard Sharpe <realrichardsharpe at gmail.com>.
    "It seems to me that if the lock is already held by another process when we
    enter this code, there is a race between the timeout and the granting. If
    the lock is subsequently granted, the process releasing the lock will signal
    the wait variable (or whatever) and our process will be scheduled. However,
    if the timeout occurs before we are scheduled, the timeout will be delivered
    first.
    
    We will have the lock but will forget we have the lock, and never release
    it."
    Jeremy.

-----------------------------------------------------------------------

Summary of changes:
 source/lib/util_tdb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Changeset truncated at 500 lines:

diff --git a/source/lib/util_tdb.c b/source/lib/util_tdb.c
index d267a92..c41df91 100644
--- a/source/lib/util_tdb.c
+++ b/source/lib/util_tdb.c
@@ -81,7 +81,7 @@ static int tdb_chainlock_with_timeout_internal( TDB_CONTEXT *tdb, TDB_DATA key,
 		alarm(0);
 		tdb_setalarm_sigptr(tdb, NULL);
 		CatchSignal(SIGALRM, SIGNAL_CAST SIG_IGN);
-		if (gotalarm) {
+		if (gotalarm && (ret == -1)) {
 			DEBUG(0,("tdb_chainlock_with_timeout_internal: alarm (%u) timed out for key %s in tdb %s\n",
 				timeout, key.dptr, tdb_name(tdb)));
 			/* TODO: If we time out waiting for a lock, it might


-- 
Samba Shared Repository