25927e068f
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 Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33283 |
||
---|---|---|
.. | ||
acl | ||
aio | ||
audit | ||
auditpipe | ||
capsicum | ||
cddl | ||
common | ||
devrandom | ||
fifo | ||
file | ||
fs | ||
geom | ||
kern | ||
kqueue | ||
mac | ||
mqueue | ||
net | ||
netgraph | ||
netinet | ||
netinet6 | ||
netipsec | ||
netmap | ||
netpfil | ||
opencrypto | ||
pjdfstest | ||
posixshm | ||
sys | ||
vfs | ||
vm | ||
vmm | ||
Makefile | ||
Makefile.depend | ||
Makefile.inc |