Yet another VNASSERT failure. This was encountered trying to chroot into a fuse squashfs mount. [57386] VNASSERT failed: VOP_ISLOCKED(vp) == LK_EXCLUSIVE || mtx_owned(&VTOFUD(vp)->cached_attr_mtx) not true at /usr/local/src/sys/fs/fuse/fuse_vnops.c:910 (fuse_vnop_close) [57386] 0xfffff80cb3c6ac08: type VREG state VSTATE_CONSTRUCTED op 0xffffffff89e6b7a8 [57386] usecount 2, writecount -5, refcount 3 seqc users 0 [57386] hold count flags () [57386] flags () [57386] v_object 0xfffff80a4602d780 ref 5 pages 28 cleanbuf 1 dirtybuf 0 [57386] lock type fuse: SHARED (count 1) [57386] nodeid: 6, parent nodeid: 0, nlookup: 1, flag: 0x2000 [57386] panic: cached attrs not locked [57386] cpuid = 20 [57386] time = 1780639234 [57386] KDB: stack backtrace: [57386] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0234c85720 [57386] vpanic() at vpanic+0x149/frame 0xfffffe0234c85850 [57386] panic() at panic+0x43/frame 0xfffffe0234c858b0 [57386] fuse_vnop_close() at fuse_vnop_close+0x329/frame 0xfffffe0234c859c0 [57386] VOP_CLOSE_APV() at VOP_CLOSE_APV+0x52/frame 0xfffffe0234c859f0 [57386] kern_execve() at kern_execve+0xac1/frame 0xfffffe0234c85d80 [57386] sys_execve() at sys_execve+0x54/frame 0xfffffe0234c85e00 [57386] amd64_syscall() at amd64_syscall+0x168/frame 0xfffffe0234c85f30 [57386] fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0234c85f30 [57386] --- syscall (0, Linux ELF64, read), rip = 0x801156300, rsp = 0x7fffffffcb20, rbp = 0 --- [57386] KDB: enter: panic # Steps to reproduce: With FreeBSD 16.0-CURRENT main-n286454-d94972174560 GENERIC: 1. Acquire a copy of archlinux-2026.06.01-x86_64.iso with SHA-256 ec7a9c89aed7a59a76266ccf723c5e88480e47d7088c4482436f882fa37c3989 2. Create a mdisk from the iso: # mdconfig -a -t vnode -f archlinux-2026.06.01-x86_64.iso -u 1 3. Mount the mdisk: # mount -t cd9660 /dev/md1 /mnt/cdrom 4. Mount the squashfs: # squashfuse /mnt/cdrom/arch/x86_64/airootfs.sfs /mnt/squashfs 5. chroot into the squashfs mount: # chroot /mnt/squashfs /bin/bash 6. Panic There are myriad other related bugs related to this. I went through as many as I could and afaict none would have covered this specific one. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283391 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291064 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293088 https://github.com/freebsd/freebsd-src/commit/7e68af7ce2c1 https://reviews.freebsd.org/D54850 https://reviews.freebsd.org/D55230 https://reviews.freebsd.org/D55755
I just encountered this myself. And I can provide easier steps to reproduce. The bug was probably introduced by 7e68af7ce2c1b892954df415774fe59fd2f1b62f , which means that it does not affect 15.0-RELEASE, but will affect 15.1-RELEASE. However, it only affects INVARIANTS kernels, so the regular GENERIC 15.1-RELEASE kernel is unaffected. Steps to Reproduce ================== Attempt to execute any file stored on a fusefs file system, with INVARIANTS enabled in the kernel:. For example: $ sudo pkg install -y e2fsprogs-core fusefs-ext2 $ truncate -s 256m /tmp/ext2.img $ mkfs.ext2 /tmp/ext2.img $ sudo fuse-ext2 -o rw+ /tmp/ext2.img /mnt $ sudo mkdir /mnt/tmp $ chmod 1777 /mnt/tmp $ cp /usr/bin/true /mnt/tmp /usr/bin/true
Linked is a review to a patch. Can you test it, Dan? FTR, the bug was not introduced by 7e68af7ce2c . It's actually been present forever, but the assertion was never enabled by default until DEBUG_VFS_LOCKS got enabled by default before 15.0-RELEASE .
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ee1c3d38a26aa63fca8e9f86c0d456800d5e2576 commit ee1c3d38a26aa63fca8e9f86c0d456800d5e2576 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2026-06-10 20:39:22 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2026-07-03 16:18:17 +0000 fusefs: fix vnode locking violations during execve Fix two locking violations that could happen during execve, while executing a file stored on fusefs. Both would cause panics on an INVARIANTS kernel after 15.0, or a DEBUG_VFS_LOCKS kernel prior to that. Neither is likely to be noticeable on a release kernel. * Don't assume that the vnode is exclusively locked during VOP_CLOSE. It usually is thanks to !MNTK_LOOKUP_SHARED, but isn't during execve, which locks the vnode outside of the lookup path. * Totally rewrite fuse_io_invalbuf. It's had a number of problems ever since its original introduction[^1]: - Don't assume that the vnode is exclusively locked. That assumption failed during execve just like the assumption in fuse_vnop_close. - Don't livelock forever if vinvalbuf returns ENOSPC or EDQUOT. - Don't attempt to handle multiple threads calling this function at the same time. That would be impossible if the vnode truly were exclusively locked. So the code was dead. Or it would've been, if the assumption hadn't been wrong. Furthermore, both vinvalbuf and vnode_pager_clean_sync only require a shared vnode lock, and are already capable of dealing with multiple simultaneous callers. - Using fvdat->flag in this way would require some sort of mutex protection, if the vnode weren't exclusively locked. * Add new test cases that trigger both of the aforementioned panics. [^1]: https://github.com/glk/fuse-freebsd/commit/efe6eb3005e7633b4e31d5e453eacbaa0cba42fa PR: 295957 Reported by: dan.kotowski@a9development.com MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D57536 sys/fs/fuse/fuse_io.c | 49 +----- sys/fs/fuse/fuse_node.h | 2 - sys/fs/fuse/fuse_vnops.c | 27 ++- tests/sys/fs/fusefs/Makefile | 2 + tests/sys/fs/fusefs/ext2-misc.sh (new) | 55 ++++++ tests/sys/fs/fusefs/misc.cc (new) | 304 +++++++++++++++++++++++++++++++++ tests/sys/fs/fusefs/mockfs.cc | 2 +- tests/sys/fs/fusefs/utils.cc | 3 +- 8 files changed, 388 insertions(+), 56 deletions(-)