nfsserver: lock vnode around calls to VOP_PATHCONF()

[kib]

Summary

I suspect that taking the vnode lock in these places should be safe because this should happen in the top-level RPC callback, which should not own any other resources.

[rmacklem]

This might make his case work, but the bug is in nfsrvd_getattr(),
where it mishandles the VV_ROOT case. Real clients never do
what his test does.

[rmacklem]

Actually the change to nfsv4_fillattr() will basically work, since
the NFS server side always calls nfsv4_fillattr() with "vp" unlocked.

It should probably be moved up into the section that does the
same thing for "naclp", since it should also check that both cred
and p are NULL (which indicates a server side call).
--> Having the server side call with it unlocked and the client

side with "vp" locked is confusing.;-)

I don't think the nfsv4_loadattr() changes are needed, since the
vnode should be locked.

I'll post a patch similar to yours for nfsv4_fillattr() soon.

[des]

In D51398#1173628, @rmacklem wrote:

Real clients never do what his test does.

What, exactly, does my test do that real clients never would?

[rmacklem]

In D51398#1173747, @des wrote:

In D51398#1173628, @rmacklem wrote:

Real clients never do what his test does.

What, exactly, does my test do that real clients never would?

I was mistaken. I thought your test was doing a Getattr on
the parent of the mount point for some reason.

All that was happening was that you had DEBUG_VFS_LOCKS
option in your kernel config, so you were catching the bug
I introduced where VOP_PATHCONF() wsa being done on an
unlocked vnode.

The patch in D51410 should fix this.

Sorry for the confusion.