From 4ac5552f257f59c2853c6dcc1d96758db89fbd4e Mon Sep 17 00:00:00 2001 From: Jeremy Allison Date: Thu, 8 Jan 2009 10:34:23 -0800 Subject: [PATCH] Fix race condition in alarm lock processing noticed by Richard Sharpe . "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. (cherry picked from commit 92c251ace583391ea1540f0ae455399f8a75cecf) --- source/lib/util_tdb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/lib/util_tdb.c b/source/lib/util_tdb.c index 82572326679..6d61fd9f719 100644 --- a/source/lib/util_tdb.c +++ b/source/lib/util_tdb.c @@ -86,7 +86,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 -- 2.11.4.GIT