Subject: Re: vn_lock(LK_RETRY) (was: Re: CVS commit: src/sys/miscfs)
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 06/20/2004 14:15:23
> > there's no problem to having a routine that won't fail.
> > and there's no problem not to checking its failure.
> I agree that there's no problem in having a routine that can't fail, nor
> ignoring any "error" return value in such a case. I still feel, though,
> that vn_lock() isn't that routine.
afaik, vn_lock(LK_RETRY) is *currently* supposed not to fail.
(if someone try to acquire a drained lock, its a bug in the caller.)
is there a way to change your feeling? :-)
> Maybe, maybe not. One advantage of our node locking protocol is that the
> locking is visable to the caller. So the caller can use the lock to
> perform a sequence of actions atomically.
you shouldn't use vnode locking for such purpose because
VOPs are allowed to be no-op as genfs_nolock.
(i know that our nfsd does such. it should be changed, IMO.)
> > btw, please answer my first question.
> > are you going to add checks on every vn_lock(LK_RETRY)?
> Not at the present time. While I think that would be a good and correct
> thing, I do not have the time nor energy to change each occurrence.
i see. thanks.
as i still disagree,
please have a discussion here (tech-kern@) before doing so..