summaryrefslogtreecommitdiff
path: root/examples/scripts/users_and_groups/adduserstogroups.pl
diff options
context:
space:
mode:
authorVolker Lendecke <vl@samba.org>2008-05-20 21:54:36 +0200
committerVolker Lendecke <vl@samba.org>2008-05-20 21:59:44 +0200
commit6ed27edbcd3ba1893636a8072c8d7a621437daf7 (patch)
tree670cce297e9dad1a82131778b2153134c400f6d7 /examples/scripts/users_and_groups/adduserstogroups.pl
parent8ca459e067c3d4f3495e0a6dafea7296e3dfb2ab (diff)
downloadsamba-6ed27edbcd3ba1893636a8072c8d7a621437daf7.tar.gz
samba-6ed27edbcd3ba1893636a8072c8d7a621437daf7.tar.bz2
samba-6ed27edbcd3ba1893636a8072c8d7a621437daf7.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 80e700e3bd73f2ffa38046bdcba7f532e25198ef)
Diffstat (limited to 'examples/scripts/users_and_groups/adduserstogroups.pl')
0 files changed, 0 insertions, 0 deletions