[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 
> 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.

> > > 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.

YAMAMOTO Takashi