Page MenuHomeFreeBSD

nfsserver: lock vnode around calls to VOP_PATHCONF()
AbandonedPublic

Authored by kib on Jul 17 2025, 10:11 PM.
Tags
None
Referenced Files
F132408229: D51398.diff
Thu, Oct 16, 4:41 PM
Unknown Object (File)
Sun, Oct 12, 10:38 PM
Unknown Object (File)
Sun, Oct 12, 10:38 PM
Unknown Object (File)
Sun, Oct 12, 11:10 AM
Unknown Object (File)
Fri, Oct 3, 5:19 PM
Unknown Object (File)
Thu, Oct 2, 1:34 PM
Unknown Object (File)
Tue, Sep 30, 9:20 AM
Unknown Object (File)
Fri, Sep 26, 12:27 PM
Subscribers

Details

Reviewers
rmacklem
des
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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.Jul 17 2025, 10:11 PM

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.

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.

Real clients never do what his test does.

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

In D51398#1173747, @des 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.