insufficient locking in profile re-reading case

insufficient locking in profile re-reading case

If profiles are open and iterators in use while the on-disk file is being
modified (see tests/threads/prof1.c), the re-reading of the file can cause data
to be freed up.  The iterator code does no locking and assumes that the profile
node tree won't be touched.

During our Monday meeting we discussed changing the iterator code to "snapshot"
the current state of the file if it were modified, so that a more consistent
picture could be returned, essentially by bumping a reference count for the
life of the iterator object.  The reference count I was thinking of turns out
to be used for a different purpose; we'd have to add another layer of
indirection, another ref count, and another mutex to accomplish this.  There
might be a more reasonable way to go about it, but I don't want to tackle it
for 1.4 when we're already shipping beta releases.

This patch just adds locking to the current iterator code so that the file data
can't be replaced while the iterator is being processed.  The inconsistent-view
issue remains.

* prof_tree.c (profile_node_iterator): When the iterator has a current file,
lock it, and unlock it before changing it or returning.

ticket: new
status: resolved
target_version: 1.4
tags: pullup

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@16932 dc483132-0cff-0310-8789-dd5450dbe970