summaryrefslogtreecommitdiff
path: root/source4/script/uninstallmodules.sh
diff options
context:
space:
mode:
authorVolker Lendecke <vl@samba.org>2008-05-20 21:54:36 +0200
committerJeremy Allison <jra@samba.org>2008-05-20 14:20:42 -0700
commitaa7e4b8e9cafaa5139b5111aa8ca042e6b6f65f4 (patch)
tree0311e25d1b76b84573cf27ac946115e982e0ae94 /source4/script/uninstallmodules.sh
parent9a975a868e949e61cb011422363cd07b4ec0ce43 (diff)
downloadsamba-aa7e4b8e9cafaa5139b5111aa8ca042e6b6f65f4.tar.gz
samba-aa7e4b8e9cafaa5139b5111aa8ca042e6b6f65f4.tar.bz2
samba-aa7e4b8e9cafaa5139b5111aa8ca042e6b6f65f4.zip
Fix nesting tdb_traverse in a transaction
Calling tdb_traverse inside a transaction led to the transaction lock being held indefinitely. This was caused by the tdb_transaction_lock/unlock inside tdb_traverse: The transaction code holds the global lock at offset TRANSACTION_LOCK. The call to tdb_transaction_lock does nothing because the transaction_lock is already being held. tdb_transaction_unlock inside tdb_wrap resets tdb->have_transaction_lock but does not release the kernel-level fcntl lock. transaction_commit later on does not release that fcntl lock either, because tdb->have_transaction_lock was already reset by tdb_transaction(). This patch does fix that problem for me. An alternative would be to make tdb->have_transaction_lock a counter that can cope with proper nesting, maybe in other places as well. Volker (This used to be commit 89543005fe2e4934b3c560c937d49304a32a7fc2)
Diffstat (limited to 'source4/script/uninstallmodules.sh')
0 files changed, 0 insertions, 0 deletions