Major issues with nfsv4

Konstantin Belousov kostikbel at
Sat Dec 12 17:51:12 UTC 2020

On Sat, Dec 12, 2020 at 05:33:06PM +0000, Rick Macklem wrote:
> Konstantin Belousov wrote:
> [stuff snipped]
> >Nullfs vnodes keep a reference on the lower vnode.  When nullfs vnode
> >caching is enabled, nullfs vnodes survive after a vfs syscall is finished.
> >
> >NFSv4 mount automatically sets flag MNTK_NULL_NOCACHE that disables nullfs
> >vnode cache.
> Thanks Kostik, I see that. (And I recall discussions about disabling the nullfs caching.)
> Now, if I understand it correctly, if vrele() is called with the vnode shared locked,
> then VOP_INACTIVE() won't be called.
> --> It is VOP_INACTIVE()/VOP_RECLAIM() in the NFSv4 client that does the closes.
> Normally the NFS client calls vput() when the vnode is locked, but is there a case
> where nullfs might cause vrele() to be called on the lower vp when it is shared
> locked? (Delaying closes until VOP_RECLAIM() would cause problems, I think?)
If vput() is called with the vnode shared-locked, it tries to upgrade to
exclusive with LK_NOWAIT.  If sleep-less upgrade fails, invalidation is

In practice, the failure to upgrade the lock is not too common, because
caller drops the last use reference on the vnode, but it still happens.

That said, I do not believe that this situation causes the problems OP
described.  I want to see what is going on in the exiting process.

> Note that, until we see the "nfsstat -c -E" we won't know if lots of opens
> are an issue anyhow.
> Thanks for the help, rick

More information about the freebsd-fs mailing list