Subject: Re: 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/21/2004 09:32:45
> > > 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().