> > > 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.
> > 
> > no.
> > 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.)
> 
> nfsd? You mean the NFS client code? No, it uses real locking now.

no, i meant nfsd.

> I agree that file systems using genfs_nolock is bad. Thus the note where I 
> spoke about how we almost have stopped using it. :-)

it seems that you misunderstand what i tried to say.
what i meant is, "nfsd relies on filesystems having real vnode locking.
it should be changed, IMO."
i don't think genfs_nolock is bad at all.
generally, i think that vnode locks should go away.
(and i know you disagree.  however, don't worry.
i have no plan to propose such a change in near future. :-)

> The place I care most is in handling PDIRUNLOCKED, especially in error
> cases. The code is correct there, so I'm happy. :-)

i think that you want to add checks at "goto bad" path in lookup().

YAMAMOTO Takashi