Subject: vn_lock(LK_RETRY) (was: Re: CVS commit: src/sys/miscfs)
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 06/18/2004 10:23:07
[moved from source-changes@]
> On Thu, Jun 17, 2004 at 11:02:07AM +0900, YAMAMOTO Takashi wrote:
> > > > how can vn_lock(LK_EXCLUSIVE | LK_RETRY) fail in this case?
> > >
> > > Somehow the lock is dying.
> > dying? can you please be more specific?
> Lock being drained, for instance. Specifically for PDIRUNLOCKED the main
> point was to handle errors in looking up '..'. If there's an error getting
> '..' and we can't then re-lock '.', this flag tells callers something
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.
> > > Yes, for it to happen we have to have
> > > wandered into the weeds, but this code methodology is to try and help us
> > > get somewhere a bit safer. i.e. not add more error states on top if we
> > > don't have to.
> > 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.
> The difference here is that you're changing the state of PDIRUNLOCK. Don't
> 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.