Subject: Re: locking bug in coda_lookup?
To: Jaromir Dolecek <jdolecek@NetBSD.org>
From: Greg Troxel <firstname.lastname@example.org>
Date: 09/05/2004 10:16:41
> 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.