summaryrefslogtreecommitdiff
path: root/source3
diff options
context:
space:
mode:
authorJeremy Allison <jra@samba.org>2009-01-08 10:36:10 -0800
committerJeremy Allison <jra@samba.org>2009-01-08 10:36:10 -0800
commitc07ea13d3077f73ad6cb28e9689b120bca6eac74 (patch)
treede6343a083435071db1a70a8ad8145167a4a57f7 /source3
parent154e08f275f1d20f0c8bdf1c876dc1ec780b1db2 (diff)
downloadsamba-c07ea13d3077f73ad6cb28e9689b120bca6eac74.tar.gz
samba-c07ea13d3077f73ad6cb28e9689b120bca6eac74.tar.bz2
samba-c07ea13d3077f73ad6cb28e9689b120bca6eac74.zip
Fix race condition in alarm lock processing noticed by Richard Sharpe <realrichardsharpe@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.
Diffstat (limited to 'source3')
-rw-r--r--source3/lib/util_tdb.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/source3/lib/util_tdb.c b/source3/lib/util_tdb.c
index bb568bc22e..8ceaa46670 100644
--- a/source3/lib/util_tdb.c
+++ b/source3/lib/util_tdb.c
@@ -64,7 +64,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