Subject: Re: locking bug in coda_lookup?
To: Greg Troxel <firstname.lastname@example.org>
From: Love <email@example.com>
Date: 09/05/2004 20:17:06
Greg Troxel <firstname.lastname@example.org> writes:
> > 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
should the lock on the child be claimed before the lock on parent is
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (NetBSD)
-----END PGP SIGNATURE-----