> It seems that this will fail if someone else has the vnode locked, and
  > there will be no retry.  From reading vn_lock, it seems that if one
  > passes LK_NOWAIT, that on encountering a locked vnode, vn_lock returns
  > immediately.  If LK_NOWAIT is not set, and LK_RETRY is also not set,
  > it seems that vn_lock will tsleep on the vnode's v_interlock, and then
  > return ENOENT instead of retrying.  The ufs code uses LK_RETRY in what
  > I think is the analogous case.
  > 
  > I don't understand why it makes sense to sleep and not retry the lock
  > - if one isn't going to retry, what's the point of sleeping?
  > 
  > So, I think that coda_lookup should pass LK_RETRY.  But I either don't
  > quite or just barely understand vnode locking, so I'd appreciate
  > advice here.

  Your analysis might be right. Does it work fine if you try
  changing the source to use LK_EXCLUSIVE|LK_RETRY in
  the vn_lock() call?

I'll patch and see, but I use coda quite a bit and it almost never
crashes these days.  I'd say if it works with LK_RETRY, we should
commit that change.  

  > Also, it seems that the coda lookup operation doesn't properly handle
  > IS_DOTDOT where the locking rules are different.  That could be
  > related to my crash instead.

  Right. If that is the case, the find will deadlock instead :)

That's never happened to me.