Hierarchical iprop project review

[Greg Hudson]

On 01/30/2014 01:28 PM, Greg Hudson wrote:
> I have finished reworking the code and have written up a detailed
> project page summarizing the design changes.

There is a potential problem with deadlock in my patch series, which
raises a design question about how we should do locking in iprop support.

Right now there is a lock on the ulog file, which is usually obtained
implicitly inside the kdb_log.c functions.  There is also the database
lock in the DB2 back end (two of them, actually, but ignore that for
now), which can be obtained explicitly with krb5_db_lock or implicitly
by performing a KDB read or write operation.  Several operations need to
serialize both resources at once, and if they lock in different orders,
deadlock can result.

Nico proposes ditching the ulog lock and just locking the database to
serialize access to the ulog.  With only one lock, there can be no
deadlock.  This approach would unnecessarily serialize ulog operations
against KDB reads and unlogged KDB updates, but that's a small cost.
Another consideration is that the LDAP KDB module does not support
locking; this is not necessarily a big deal since iprop already doesn't
work with an LDAP master, but we would be further entrenching that
restriction in the iprop design.

The less aggressive approach is to define an order (such as "always lock
ulog before DB"), document this order in appropriately placed comments,
and make sure all of the aforementioned operations obey the order.
Right now kdb5_util dump is the outlier, so it would have to expicitly
lock the ulog before locking the DB.