summaryrefslogtreecommitdiffstats
path: root/ctdb/include
diff options
context:
space:
mode:
authorAndrew Tridgell <tridge@samba.org>2007-04-19 10:03:20 +1000
committerAndrew Tridgell <tridge@samba.org>2007-04-19 10:03:20 +1000
commitfde5a66531af99c6d6ef665ccbfbb4944bdefdd3 (patch)
tree74d96c5b87c05e70bf696bd4319102dc12fdf221 /ctdb/include
parenta3ab61b384c90858df6af52f386daa71025767f4 (diff)
downloadsamba-fde5a66531af99c6d6ef665ccbfbb4944bdefdd3.tar.gz
samba-fde5a66531af99c6d6ef665ccbfbb4944bdefdd3.tar.xz
samba-fde5a66531af99c6d6ef665ccbfbb4944bdefdd3.zip
avoid a deadlock the fetch_lock code. The deadlock could happen when
a client held the chainlock, and the daemon received a dmaster reply at the same time. The daemon would not be able to process the dmaster reply, due to the lock, but the fetch lock cannot make progres until the dmaster reply is processed. The solution is to not hold the lock in the client while talking to the daemon. The client has to retry the lock after the record has migrated. This means that forward progress is not guaranteed. We'll have to see if that matters in practice. (This used to be ctdb commit 737e5a1253cb048222c595a474aff71c99fc554f)
Diffstat (limited to 'ctdb/include')
-rw-r--r--ctdb/include/ctdb_private.h4
1 files changed, 0 insertions, 4 deletions
diff --git a/ctdb/include/ctdb_private.h b/ctdb/include/ctdb_private.h
index 36a6c8de5d..4b97c669cb 100644
--- a/ctdb/include/ctdb_private.h
+++ b/ctdb/include/ctdb_private.h
@@ -323,7 +323,6 @@ struct ctdb_reply_connect_wait {
struct ctdb_req_fetch_lock {
struct ctdb_req_header hdr;
- struct ctdb_ltdb_header header;
uint32_t db_id;
uint32_t keylen;
uint8_t key[1]; /* key[] */
@@ -332,9 +331,6 @@ struct ctdb_req_fetch_lock {
struct ctdb_reply_fetch_lock {
struct ctdb_req_header hdr;
uint32_t state;
- struct ctdb_ltdb_header header;
- uint32_t datalen;
- uint8_t data[1]; /* data[] */
};
/* internal prototypes */