Please send follow-ups by replying (without quoting) to a message you 
receive from rt@krbdev.mit.edu, not by forwarding them to 
krbdev@mit.edu.  We've been scooping these follow-ups out of the krbdev 
moderation queue and appending them to the ticket.

I believe the performance problem you noted was actually introduced by 
your first patch.  If you look at the code you moved in that patch, 
you'll see that one of the things it does is set log_ctx->iproprole = 
IPROP_NULL before restore_dump().  The other part of the third patch 
should be unnecessary, because ulog_lock() does nothing if iproprole is 
IPROP_NULL.

Your third patch also seems broken, in that setting log_ctx->iproprole = 
IPROP_NULL before restore_dump() will prevent the ulog from being 
updated afterwards.  On master 
(https://github.com/krb5/krb5/commit/825fa2be6f119677a09acccb109ab976cfc
601f8) I worked around this by setting iproprole to IPROP_SLAVE instead 
of IPROP_NULL, but that only works because in master, kdb5.c only calls 
ulog_lock() if iproprole is IPROP_MASTER.