Subject: Re: vn_lock(LK_RETRY) (was: Re: CVS commit: src/sys/miscfs)
To: YAMAMOTO Takashi <>
From: Bill Studenmund <>
List: tech-kern
Date: 06/18/2004 19:57:25
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 18, 2004 at 10:23:07AM +0900, YAMAMOTO Takashi wrote:
> [moved from source-changes@]
> > On Thu, Jun 17, 2004 at 11:02:07AM +0900, YAMAMOTO Takashi wrote:
> > point was to handle errors in looking up '..'. If there's an error gett=
> > '..' and we can't then re-lock '.', this flag tells callers something=
> > happened.
> lockmgr() will panic in that case.  thus no errors are returned.
> usually, VOP_LOCK won't be called because VXLOCK is set in that case.
> layered filesystems are broken in that respect, though.

Actually, lockmgr() will only panic if DIAGNOSTIC is defined. I'm not sure=
if I really like what it does otherwise, which is just continue on. I=20
think I'd rather it return some sort of error. But I'm not willing to=20
fight for that today..

> > > > Yes, for it to happen we have to have
> > > > wandered into the weeds, but this code methodology is to try and he=
lp us=20
> > > > get somewhere a bit safer. i.e. not add more error states on top if=
> > > > don't have to.
> > >=20
> > > we have many code which assume that vn_lock with LK_RETRY never fails.
> > > are you going to add error checks on all of them?
> > > i think that it just bloats the code without any benefits.
> >=20
> > The difference here is that you're changing the state of PDIRUNLOCK. Do=
> > clear it if you don't know the lock succeeded.
> actually, there's no much differences.
> if vn_lock(LK_RETRY) can fail,
> all callers should check it and shouldn't unlock the vnode after an error.
> it's better to make sure that vn_lock(LK_RETRY) won't fail rather than
> letting all callers check error conditions, IMO.

Well, then I guess we'll have to disagree. I'm always concerned by what=20
happens if a routine that "can't fail" realizes it is going to fail. It=20
either has to do something like panic, or it has to pretend things are ok.=
If instead it can fail, it can tell the upper layers that something is=20
wrong. They can choose to not do anything, but they've been told.

Also, consider something like a distributed file system with a lock=20
manager (as in a separate server). Say you can't contact the lock manager.=
Do you really sit there in uninterruptable sleep for ever? Yes, how and=20
when you decide to give up is something the admin decides (as it should=20
be). But the scenario shows a reason to have vn_lock(LK_RETRY) fail.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)