Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) From: ghudson@mit.edu Subject: SVN Commit X-RT-Original-Encoding: iso-8859-1 Content-Length: 1268 Fix lock inconsistency in ctx_unlock() The lock inconsistency fixed here is quite possibly the same as described in https://bugzilla.redhat.com/show_bug.cgi?id=586032 . The problem is that ctx_unlock() fails to unlock the principal DB if it fails to unlock the policy DB, and this happens when ctx_lock() fails to lock the policy DB (likely because the caller is racing against a kdb5_util load, which will be using a "permanent" lock, meaning that the lock file will be unlinked after acquiring the lock). The fix is to perform both unlock operations *then* handle any errors that either or both might have returned. Additionally, we don't really need or want to use non-blocking locks, and we certainly don't want to sleep(1) in krb5kdc (possibly several times, as there was a loop over this) when either of the principal or policy DB is locked. Some callers still request non-blocking locks, and ctx_lock() still honors this. https://github.com/krb5/krb5/commit/29ee39baa919361ae08e26caab896890d5cb3eb4 Author: Nicolas Williams Committer: Greg Hudson Commit: 29ee39baa919361ae08e26caab896890d5cb3eb4 Branch: master src/plugins/kdb/db2/kdb_db2.c | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-)