src/sys/fs/fuse, branch main

fusefs: better handling for low-memory conditions

2026-04-20T21:06:57Z

Under conditions of low memory, getblk can fail. fusefs was not handling those failures very systematically. It was always using PCATCH, which appears to have been originally copy/pasted from the NFS client code, but isn't always appropriate: * During fuse_vnode_setsize_immediate, which can be called from many different VOPs and from the vn_delayed_setsize mechanism, remove PCATCH. Some of these callers cannot tolerate allocate failure. * In fuse_inval_buf_range, don't assume that getblk will always succeed. * When calling fuse_inval_buf_range from VOP_ALLOCATE, VOP_COPY_FILE_RANGE, or VOP_WRITE (with IO_DIRECT), return EINTR if the allocation fails. * When calling fuse_inval_buf_range from VOP_DEALLOCATE, remove PCATCH. This VOP must not fail with EINTR. No new tests, because I can't force any particular getblk call to fail. PR: 293957 Sponsored by: ConnectWise Reported by: zjk7@wp.pl MFC after: 1 week

fusefs: redo vnode attribute locking

2026-03-12T16:11:25Z

Previously most fields in fuse_vnode_data were protected by the vnode lock. But because DEBUG_VFS_LOCKS was never enabled by default until stable/15 the assertions were never checked, and many were wrong. Others were missing. This led to panics in stable/15 and 16.0-CURRENT, when a vnode was expected to be exclusively locked but wasn't, for fuse file systems that mount with "-o async". In some places it isn't possible to exclusively lock the vnode when accessing these fields. So protect them with a new mutex instead. This fixes panics and unprotected field accesses in VOP_READ, VOP_COPY_FILE_RANGE, VOP_GETATTR, VOP_BMAP, and FUSE_NOTIFY_INVAL_ENTRY. Add assertions everywhere the protected fields are accessed. Lock the vnode exclusively when handling FUSE_NOTIFY_INVAL_INODE. During fuse_vnode_setsize, if the vnode isn't already exclusively locked, use the vn_delayed_setsize mechanism. This fixes panics during VOP_READ or VOP_GETATTR. Also, ensure that fuse_vnop_rename locks the "from" vnode. Finally, reorder elements in struct fuse_vnode_data to reduce the structure size. Fixes: 283391 Reported by: kargl, markj, vishwin, Abdelkader Boudih, groenveld@acm.org MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D55230

VOP_RENAME(9): add flags argument

2026-03-05T23:46:53Z

Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D55539

fusefs: remove the obsolete rename_lock

2026-02-22T17:08:27Z

This lock was included in the original GSoC submission. Its purpose seems to have been to prevent concurrent FUSE_RENAME operations for the current mountpoint, as well as to synchronize FUSE_RENAME with fuse_vnode_setparent. But it's obsolete, now that ef6ea91593e added mnt_renamelock . MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D55231

fusefs: style

2026-01-24T16:02:44Z

Reorder macro definitions.

fusefs: Implement support for the auto_unmount option kernel-side

2026-01-24T10:06:16Z

libfuse clients may pass the "-o auto_unmount" flag to ensure that the mountpoint will get unmounted even if the server terminate abnormally. Without this flag sending KILL to a FUSE daemon leaves its mountpoint mounted. Approved by: asomers Differential Revision: https://reviews.freebsd.org/D53086

fusefs: support FUSE_IOCTL

2026-01-10T00:06:21Z

MFC After: 1 week Signed-off-by: CismonX Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1470

fs/fuse: use dedicated category per source file

2025-12-29T01:16:25Z

Submitted by: mckusick Reviewed by: emaste, mckusick Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54380

fusefs: standardize on OPNOTSUPP for posix_fallocate(2)

2025-11-05T00:30:58Z

POSIX Issue 7 had allowed EINVAL for this case, but issue 8 moves it to ENOTSUP instead. ZFS uses the latter and we have some software in ports already that's wanting to use that to detect the filesystem not supporting it, so let's standardize on it. Reviewed by: imp (previous version), asomers, kib Differential Revision: https://reviews.freebsd.org/D53535

fusefs: respect the server's FUSE_SETXATTR_EXT flag

2025-11-03T17:14:35Z

FUSE protocol 7.33 extended the FUSE_SETXATTR request format. But the extension is optional. The server must opt-in by setting the FUSE_SETXATTR_IN flag during FUSE_INIT. We were wrongly using the extended format for any server using protocol 7.33 or later. PR: 290547 Co-authored-by: CismonX Fixes: d5e3cf41e89 ("fusefs: Upgrade FUSE protocol to version 7.33") MFC after: 3 days