Page MenuHomeFreeBSD

fusefs: correctly handle an inode that changes file types
ClosedPublic

Authored by asomers on Dec 6 2021, 5:53 AM.
Tags
None
Referenced Files
F154935349: D33283.diff
Thu, Apr 30, 4:17 AM
Unknown Object (File)
Mon, Apr 27, 8:02 AM
Unknown Object (File)
Fri, Apr 24, 9:59 PM
Unknown Object (File)
Tue, Apr 21, 1:52 PM
Unknown Object (File)
Mon, Apr 20, 9:37 AM
Unknown Object (File)
Mon, Apr 20, 5:18 AM
Unknown Object (File)
Mon, Apr 20, 2:51 AM
Unknown Object (File)
Tue, Apr 14, 10:40 PM

Details

Summary

Correctly handle the situation where a FUSE server unlinks a file, then
creates a new file of a different type but with the same inode number.
Previously fuse_vnop_lookup in this situation would return EAGAIN. But
since it didn't call vgone(), the vnode couldn't be reused right away.
Fix this by immediately calling vgone() and reallocating a new vnode.

This problem can occur in three code paths, during VOP_LOOKUP,
VOP_SETATTR, or following FUSE_GETATTR, which usually happens during
VOP_GETATTR but can occur during other vops, too. Note that the correct
response actually doesn't depend on whether the entry cache has expired.
In fact, during VOP_LOOKUP, we can't even tell. Either it has expired
already, or else the vnode got reclaimed by vnlru.

Also, correct the error code during the VOP_SETATTR path.

PR: 258022
Reported by: chogata@moosefs.pro
MFC after: 2 weeks

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 43167
Build 40055: arc lint + arc unit