github-starred/RhapsodiOS

Watch

Fork 0

mirror of https://github.com/RhapsodiOS/RhapsodiOS.git synced 2026-11-03 22:01:40 -07:00

unlink panics UFS (rename: lost dir entry, free vnode isn't, vget: v_usecount) #39

New issue

Closed

opened 2026-11-03 22:02:45 -07:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-11-03 22:02:45 -07:00

Owner

Originally created by @raynorpat on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/45

Symptom

Concurrent namespace churn on one UFS directory tree panics the kernel within a handful of runs. Three different panics have been seen:

Panic	Where	Kernel
`rename: lost dir entry`	`bsd/ufs/ufs/ufs_vnops.c:1215` or `:1231` (`ufs_rename`)	v2 image kernel (master + ffs fixes)
`free vnode isn't: v_type = 8, v_usecount = -1`	`bsd/vfs/vfs_subr.c:455` (`getnewvnode`)	ffs-perf kernel (with the MapFS fix `7ed3069ab`)
`vget: v_usecount`	`bsd/vfs/vfs_subr.c:876`	v2 image kernel, with directory renames removed from the test

v_type = 8 is VBAD: a vnode that was reclaimed or revoked, sitting on the free list with a use count of -1, so something called vrele once too often. The vget panic is the same reference count gone wrong from the other side. That it happens even with directory renames removed suggests the refcount bug is not only in the directory-rename path.

Reproduce

stress-fs tree from the stress suite (src/Commands/stress, ffs-perf branch). It runs 4 processes doing random mkdir/rmdir/create/unlink/rename (of files, subdirectories and top-level directories) in a shared 3-level tree d<0-7>/d<0-7>/f<0-7> under /tmp, then walks it:

./fs/stress-fs -n 4 -s 5 tree      # repeat with seeds 1..40

It panicked on about the 4th or 5th run in each attempt: image kernel seed 5, ffs-perf kernel seed 4, image kernel without directory renames seed 16.
The seed fixes each worker's sequence of operations, but not the interleaving, so a single seed does not replay deterministically.
The serial log was empty; the panic text came from a QMP screendump.
The guest was the i386 v2 image under QEMU TCG (-cpu pentium), uniprocessor, 128 MB. The problem must therefore be in sleep/wakeup interleaving, not SMP.

Where to look

ufs_rename (ufs_vnops.c ~1100-1300):
- The source entry is re-looked up with relookup() after the target is entered. The code assumes a directory source cannot disappear in between, because its link count blocks rmdir and IRENAME blocks a concurrent rename.
- The panic shows that assumption failing: either IRENAME is not honoured on every path (e.g. a rename of the parent or of a sibling that moves the source), or a concurrent rename/rmdir slips in while ufs_rename sleeps in relookup or a block read.
- 4.4BSD-Lite2 and later NetBSD/FreeBSD changed this code to return an error instead of panicking, and to serialise directory renames. FreeBSD uses a per-mount rename lock; NetBSD later used genfs_rename.
Reference counting on the paths a failed or racing rename takes:
- The vrele/vput calls on the error and "source vanished" branches, for example vrele(ap->a_fvp) at ufs_vnops.c:1216.
- ufs_rmdir/ufs_remove racing with vget of a vnode being reclaimed (the VXLOCK path at vfs_subr.c:863-868).
- A double vrele would produce exactly v_usecount = -1 on a VBAD vnode.
Other filesystems: msdosfs (msdosfs_vnops.c:1183/1204) and ext2fs (ext2fs_vnops.c:808/824) carry the same lost dir entry panics and probably the same race.

Suggested fix direction

Stop panicking: make the "source vanished" cases return ENOENT instead of panicking, with correct releases on every exit path.
Serialise directory renames per mount. A simple sleep lock is enough on this uniprocessor kernel.
Audit refcounts: check every vrele/vput in ufs_rename, ufs_rmdir, ufs_remove and relookup against its reference.
Regression test: stress-fs -n 4 tree in a loop of 40 seeds should run clean afterwards.

Impact

Any concurrent build or make clean, mail spool, or package install that renames and removes directories while others do the same can panic the system. This may also be behind some of the unexplained build-time crashes seen earlier.

Related: #41, #42, #43, also found by the stress suite.

Originally created by @raynorpat on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/45 ## Symptom Concurrent namespace churn on one UFS directory tree panics the kernel within a handful of runs. Three different panics have been seen: | Panic | Where | Kernel | |---|---|---| | `rename: lost dir entry` | `bsd/ufs/ufs/ufs_vnops.c:1215` or `:1231` (`ufs_rename`) | v2 image kernel (master + ffs fixes) | | `free vnode isn't: v_type = 8, v_usecount = -1` | `bsd/vfs/vfs_subr.c:455` (`getnewvnode`) | ffs-perf kernel (with the MapFS fix 7ed3069ab) | | `vget: v_usecount` | `bsd/vfs/vfs_subr.c:876` | v2 image kernel, with directory renames removed from the test | `v_type = 8` is `VBAD`: a vnode that was reclaimed or revoked, sitting on the free list with a use count of -1, so something called `vrele` once too often. The `vget` panic is the same reference count gone wrong from the other side. That it happens even with directory renames removed suggests the refcount bug is not only in the directory-rename path. ## Reproduce `stress-fs tree` from the stress suite (`src/Commands/stress`, ffs-perf branch). It runs 4 processes doing random `mkdir`/`rmdir`/create/`unlink`/`rename` (of files, subdirectories and top-level directories) in a shared 3-level tree `d<0-7>/d<0-7>/f<0-7>` under `/tmp`, then walks it: ``` ./fs/stress-fs -n 4 -s 5 tree # repeat with seeds 1..40 ``` - It panicked on about the 4th or 5th run in each attempt: image kernel seed 5, ffs-perf kernel seed 4, image kernel without directory renames seed 16. - The seed fixes each worker's sequence of operations, but not the interleaving, so a single seed does not replay deterministically. - The serial log was empty; the panic text came from a QMP screendump. - The guest was the i386 v2 image under QEMU TCG (`-cpu pentium`), uniprocessor, 128 MB. The problem must therefore be in sleep/wakeup interleaving, not SMP. ## Where to look - **`ufs_rename` (`ufs_vnops.c` ~1100-1300):** - The source entry is re-looked up with `relookup()` after the target is entered. The code assumes a directory source cannot disappear in between, because its link count blocks `rmdir` and `IRENAME` blocks a concurrent rename. - The panic shows that assumption failing: either `IRENAME` is not honoured on every path (e.g. a rename of the *parent* or of a sibling that moves the source), or a concurrent rename/rmdir slips in while `ufs_rename` sleeps in `relookup` or a block read. - 4.4BSD-Lite2 and later NetBSD/FreeBSD changed this code to return an error instead of panicking, and to serialise directory renames. FreeBSD uses a per-mount rename lock; NetBSD later used `genfs_rename`. - **Reference counting on the paths a failed or racing rename takes:** - The `vrele`/`vput` calls on the error and "source vanished" branches, for example `vrele(ap->a_fvp)` at `ufs_vnops.c:1216`. - `ufs_rmdir`/`ufs_remove` racing with `vget` of a vnode being reclaimed (the `VXLOCK` path at `vfs_subr.c:863-868`). - A double `vrele` would produce exactly `v_usecount = -1` on a `VBAD` vnode. - **Other filesystems:** `msdosfs` (`msdosfs_vnops.c:1183/1204`) and `ext2fs` (`ext2fs_vnops.c:808/824`) carry the same `lost dir entry` panics and probably the same race. ## Suggested fix direction - **Stop panicking:** make the "source vanished" cases return `ENOENT` instead of panicking, with correct releases on every exit path. - **Serialise directory renames per mount.** A simple sleep lock is enough on this uniprocessor kernel. - **Audit refcounts:** check every `vrele`/`vput` in `ufs_rename`, `ufs_rmdir`, `ufs_remove` and `relookup` against its reference. - **Regression test:** `stress-fs -n 4 tree` in a loop of 40 seeds should run clean afterwards. ## Impact Any concurrent build or `make clean`, mail spool, or package install that renames and removes directories while others do the same can panic the system. This may also be behind some of the unexplained build-time crashes seen earlier. Related: #41, #42, #43, also found by the stress suite.

gitea-mirror

2026-11-03 22:02:45 -07:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-11-03 22:02:49 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 14, 2026):

Fixed on branch fs-races (commits 9db81ac41 and 690848e2b), not yet merged to master.

Two causes, both in ufs_rename:

The source name is looked up in the syscall before the source vnode is locked. A concurrent rmdir or rename in that window left the source entry missing or pointing at a different inode, and ufs_rename hit panic("rename: lost dir entry"). For directory renames it now re-checks the source name before changing anything and returns ENOENT. (9db81ac41)
relookup() does vput(dvp) when its lookup fails, but the rename syscall still releases the SAVESTART start directory afterwards. A failed relookup in ufs_rename therefore dropped one reference too many: use count -1 on a vnode on the free list, which is the free vnode isn't: v_type = 8, v_usecount = -1 and vget: v_usecount panics. ufs_rename now calls a small ufs_relookup() wrapper that takes an extra reference first, the same pattern as union_relookup. (690848e2b)

Tested on an i386 QEMU guest (128 MB, snapshot of the v2 image). With only the first commit, stress-fs -n 4 tree still panicked on every seed 1..10. With both commits, seeds 1..200 all pass with no panic, and -n 8 -i 3000 tree passes on seeds 101..106.

Not done:

msdosfs and ext2fs have the same relookup pattern and probably the same use-count bug. I did not change them.
The fvp == tvp branch of ufs_rename would dereference NULL if its relookup fails.
The issue's third panic (vget with directory renames removed from the test) was not run separately.

Closing as fixed for UFS; the other filesystems should get their own issue.

@raynorpat commented on GitHub (Oct 14, 2026): Fixed on branch `fs-races` (commits 9db81ac41 and 690848e2b), not yet merged to master. Two causes, both in `ufs_rename`: 1. The source name is looked up in the syscall before the source vnode is locked. A concurrent `rmdir` or rename in that window left the source entry missing or pointing at a different inode, and `ufs_rename` hit `panic("rename: lost dir entry")`. For directory renames it now re-checks the source name before changing anything and returns ENOENT. (9db81ac41) 2. `relookup()` does `vput(dvp)` when its lookup fails, but the rename syscall still releases the SAVESTART start directory afterwards. A failed relookup in `ufs_rename` therefore dropped one reference too many: use count -1 on a vnode on the free list, which is the `free vnode isn't: v_type = 8, v_usecount = -1` and `vget: v_usecount` panics. `ufs_rename` now calls a small `ufs_relookup()` wrapper that takes an extra reference first, the same pattern as `union_relookup`. (690848e2b) Tested on an i386 QEMU guest (128 MB, snapshot of the v2 image). With only the first commit, `stress-fs -n 4 tree` still panicked on every seed 1..10. With both commits, seeds 1..200 all pass with no panic, and `-n 8 -i 3000 tree` passes on seeds 101..106. Not done: - msdosfs and ext2fs have the same `relookup` pattern and probably the same use-count bug. I did not change them. - The `fvp == tvp` branch of `ufs_rename` would dereference NULL if its `relookup` fails. - The issue's third panic (`vget` with directory renames removed from the test) was not run separately. Closing as fixed for UFS; the other filesystems should get their own issue.

gitea-mirror commented

2026-11-03 22:02:59 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 14, 2026):

Follow-up on the items listed as not done above. Two more commits on branch fs-races (not yet merged to master):

b2381210b: ext2fs and msdosfs. ext2fs_rename is a copy of the UFS code, so it gets the same two fixes: re-check the source name for directory renames before changing anything, and keep the start-directory reference when a relookup fails. msdosfs_rename gets the same source re-check, done before the target entry is removed, and the extra reference at its target-directory relookup. Its source-directory relookup already balances its references, so I left it alone. The reference-keeping helper is now a shared relookup_startdir() in vfs_lookup.c, which UFS uses as well.
6f587a3f9: the fvp == tvp branch of ufs_rename and ext2fs_rename called VOP_REMOVE with the result of an unchecked relookup. If the source name was already gone that was a NULL dereference; it now returns 0.

Status: these two commits have not been built or run yet. A kernel build and tree-stress run on UFS, msdosfs and ext2fs volumes is in progress, and I'll post the results here.

@raynorpat commented on GitHub (Oct 14, 2026): Follow-up on the items listed as not done above. Two more commits on branch `fs-races` (not yet merged to master): - `b2381210b`: ext2fs and msdosfs. `ext2fs_rename` is a copy of the UFS code, so it gets the same two fixes: re-check the source name for directory renames before changing anything, and keep the start-directory reference when a `relookup` fails. `msdosfs_rename` gets the same source re-check, done before the target entry is removed, and the extra reference at its target-directory `relookup`. Its source-directory `relookup` already balances its references, so I left it alone. The reference-keeping helper is now a shared `relookup_startdir()` in `vfs_lookup.c`, which UFS uses as well. - `6f587a3f9`: the `fvp == tvp` branch of `ufs_rename` and `ext2fs_rename` called `VOP_REMOVE` with the result of an unchecked `relookup`. If the source name was already gone that was a NULL dereference; it now returns 0. Status: these two commits have not been built or run yet. A kernel build and tree-stress run on UFS, msdosfs and ext2fs volumes is in progress, and I'll post the results here.

gitea-mirror commented

2026-11-03 22:03:02 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 14, 2026):

Test results for the follow-up commits.

Kernel k3 is fs-races at 89e39d0b2, which has the ext2fs/msdosfs changes, the NULL-deref fix, and a rework of the msdosfs re-check that unlocks the target before relooking up the source. Each run uses a fresh snapshot guest at 128 MB, running stress-fs -n 4 -s <seed> tree.

UFS root: seeds 1..40 all pass.
UFS on a second disk: seeds 1..60 all pass.
ext2fs, stock kernel: 4 of 4 seeds panic (ext2fs_rename: lost dir entry three times, free vnode isn't: v_type = 8, v_usecount = -1 once).
ext2fs, k3: those panics are gone. 48 of 48 seeds pass in one boot, and -n 1 passes 60 of 60. But with -n 4 it still hangs intermittently, usually within 10 to 50 seeds. The CPU spins in the lockmgr interlock in vfs_busy, reached from rename → namei → lookup crossing the ext2 mount point, and the mnt_lock word holds a pointer value. Not root-caused yet, and not yet known whether it predates these changes.
msdosfs: msdosfs is not in the i386 kernel config, and turning it on hits compile errors that were already there (PDIRUNLOCK, NDF_ONLY_PNBUF, msdos_vfsops, a 2-argument VOP_STRATEGY). So the msdosfs rename change has not run.

The UFS part is merged into ffs-perf (merge e2baceb11), not master: 76c273754, 9db81ac41, 690848e2b, plus 508cac1b4, which carries the shared relookup_startdir() and the UFS half of the NULL-deref fix. These UFS/VFS files are identical to what k3 ran. The ext2fs and msdosfs commits stay on fs-races while the ext2fs hang and the msdosfs build are worked on.

@raynorpat commented on GitHub (Oct 14, 2026): Test results for the follow-up commits. Kernel k3 is `fs-races` at 89e39d0b2, which has the ext2fs/msdosfs changes, the NULL-deref fix, and a rework of the msdosfs re-check that unlocks the target before relooking up the source. Each run uses a fresh snapshot guest at 128 MB, running `stress-fs -n 4 -s <seed> tree`. - **UFS root:** seeds 1..40 all pass. - **UFS on a second disk:** seeds 1..60 all pass. - **ext2fs, stock kernel:** 4 of 4 seeds panic (`ext2fs_rename: lost dir entry` three times, `free vnode isn't: v_type = 8, v_usecount = -1` once). - **ext2fs, k3:** those panics are gone. 48 of 48 seeds pass in one boot, and `-n 1` passes 60 of 60. But with `-n 4` it still hangs intermittently, usually within 10 to 50 seeds. The CPU spins in the lockmgr interlock in `vfs_busy`, reached from rename → namei → lookup crossing the ext2 mount point, and the `mnt_lock` word holds a pointer value. Not root-caused yet, and not yet known whether it predates these changes. - **msdosfs:** msdosfs is not in the i386 kernel config, and turning it on hits compile errors that were already there (`PDIRUNLOCK`, `NDF_ONLY_PNBUF`, `msdos_vfsops`, a 2-argument `VOP_STRATEGY`). So the msdosfs rename change has not run. The UFS part is merged into `ffs-perf` (merge e2baceb11), not master: 76c273754, 9db81ac41, 690848e2b, plus 508cac1b4, which carries the shared `relookup_startdir()` and the UFS half of the NULL-deref fix. These UFS/VFS files are identical to what k3 ran. The ext2fs and msdosfs commits stay on `fs-races` while the ext2fs hang and the msdosfs build are worked on.

gitea-mirror commented

2026-11-03 22:03:02 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 15, 2026):

The ext2fs hang is fixed, and it was not a rename bug.

Root cause. struct vnode keeps v_mountedhere (for directories) and v_vm_info (for regular files) in the same union. When an unlinked ext2 file goes inactive, ext2fs_inactive frees the inode number before it recycles the vnode. ext2 hands out the lowest free inode, so a concurrent mkdir can get that number back. ext2fs_vget then finds the old file's vnode, still in the inode hash, and ext2fs_mkdir makes it a directory. The old file's vm_info pointer is now read as v_mountedhere, so the next lookup through that directory calls vfs_busy on a vm_info. The word at the mount lock's interlock offset is vm_info->vnode, a pointer, so lockmgr spins forever. gdbstub dumps show exactly this: the mp passed to vfs_busy is the directory's own former vm_info.

This was already in the code, not caused by the rename changes. The stock kernel's rename panics fired first and hid it.

Fix. ext2fs_valloc now frees a reused vnode's vm_info and resets v_type, the same cleanup vclean does (9c0fd8de6).

Results on the fixed kernel, stress-fs -n 4 tree on a 128 MB guest:

ext2fs, seeds 1..100: 100 of 100 pass, on each of two boots.
ext2fs, seeds 101..200: 100 of 100 pass, on a third boot.
UFS on a second disk, seeds 1..40: 40 of 40 pass.
The previous kernel hung on 2 of 2 boots with the same harness.

The ext2fs commits are merged into ffs-perf (merge ab9388565); the ext2fs sources there are the ones that were tested. msdosfs is still being worked on, on its own branch.

UFS has the same latent pattern: ufs_inactive also frees the inode before recycling the vnode. It probably does not show up because FFS rarely hands a just-freed inode straight back. It is not fixed or tested yet.

@raynorpat commented on GitHub (Oct 15, 2026): The ext2fs hang is fixed, and it was not a rename bug. **Root cause.** `struct vnode` keeps `v_mountedhere` (for directories) and `v_vm_info` (for regular files) in the same union. When an unlinked ext2 file goes inactive, `ext2fs_inactive` frees the inode number before it recycles the vnode. ext2 hands out the lowest free inode, so a concurrent mkdir can get that number back. `ext2fs_vget` then finds the old file's vnode, still in the inode hash, and `ext2fs_mkdir` makes it a directory. The old file's `vm_info` pointer is now read as `v_mountedhere`, so the next lookup through that directory calls `vfs_busy` on a `vm_info`. The word at the mount lock's interlock offset is `vm_info->vnode`, a pointer, so `lockmgr` spins forever. gdbstub dumps show exactly this: the `mp` passed to `vfs_busy` is the directory's own former `vm_info`. This was already in the code, not caused by the rename changes. The stock kernel's rename panics fired first and hid it. **Fix.** `ext2fs_valloc` now frees a reused vnode's `vm_info` and resets `v_type`, the same cleanup `vclean` does (9c0fd8de6). **Results** on the fixed kernel, `stress-fs -n 4 tree` on a 128 MB guest: - ext2fs, seeds 1..100: 100 of 100 pass, on each of two boots. - ext2fs, seeds 101..200: 100 of 100 pass, on a third boot. - UFS on a second disk, seeds 1..40: 40 of 40 pass. - The previous kernel hung on 2 of 2 boots with the same harness. The ext2fs commits are merged into `ffs-perf` (merge ab9388565); the ext2fs sources there are the ones that were tested. msdosfs is still being worked on, on its own branch. UFS has the same latent pattern: `ufs_inactive` also frees the inode before recycling the vnode. It probably does not show up because FFS rarely hands a just-freed inode straight back. It is not fixed or tested yet.

gitea-mirror commented

2026-11-03 22:03:03 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 15, 2026):

msdosfs is done, and the rename fix is confirmed there too.

msdosfs had never been compiled into the i386 kernel. Five commits make it build and work:

Compile fixes: FreeBSD-only calls and flags (PDIRUNLOCK, NDFREE, vn_isdisk, malloc/free, the 2-argument VOP_STRATEGY, vtruncbuf and others) replaced with this kernel's equivalents.
Lock hang: create, mkdir, mknod, remove, rmdir, link and symlink now release the directory and name buffer, as this kernel's callers expect. Before this the mount root stayed locked after the first file was created.
Stale data: a FreeBSD 4.11 bug in extendfile keyed its zeroed buffers by sector instead of by cluster. Truncate followed by extend could return old bytes, or a late zero-write could overwrite real data.

Tested on a 128 MB guest. Smoke tests pass on FAT16 and FAT32 (create, write, read, long names, mkdir and rmdir, renames, truncate and extend, remount). fsck_msdos was clean after every stress seed.

Kernel	Volume	`stress-fs tree`	Result
With fix	FAT16	`-n 1`, seeds 1..40	40 of 40 pass
With fix	FAT16	`-n 4`, seeds 1..200	200 of 200 pass
With fix	FAT32	`-n 4`, seeds 1..40	40 of 40 pass
Without the rename fix	FAT16	`-n 4`, seeds 1..40	24 of 40 panic with `rename: lost dir entry`

Merged into ffs-perf; the msdosfs sources there are the ones that were tested. msdosfs is not yet turned on in the shipped i386 kernel config. Not tested: executing or mmap-ing files on msdosfs, since msdosfs never sets up per-file VM info and its mmap entry returns an error.

@raynorpat commented on GitHub (Oct 15, 2026): msdosfs is done, and the rename fix is confirmed there too. msdosfs had never been compiled into the i386 kernel. Five commits make it build and work: - **Compile fixes:** FreeBSD-only calls and flags (`PDIRUNLOCK`, `NDFREE`, `vn_isdisk`, `malloc`/`free`, the 2-argument `VOP_STRATEGY`, `vtruncbuf` and others) replaced with this kernel's equivalents. - **Lock hang:** create, mkdir, mknod, remove, rmdir, link and symlink now release the directory and name buffer, as this kernel's callers expect. Before this the mount root stayed locked after the first file was created. - **Stale data:** a FreeBSD 4.11 bug in `extendfile` keyed its zeroed buffers by sector instead of by cluster. Truncate followed by extend could return old bytes, or a late zero-write could overwrite real data. Tested on a 128 MB guest. Smoke tests pass on FAT16 and FAT32 (create, write, read, long names, mkdir and rmdir, renames, truncate and extend, remount). `fsck_msdos` was clean after every stress seed. | Kernel | Volume | `stress-fs tree` | Result | |---|---|---|---| | With fix | FAT16 | `-n 1`, seeds 1..40 | 40 of 40 pass | | With fix | FAT16 | `-n 4`, seeds 1..200 | 200 of 200 pass | | With fix | FAT32 | `-n 4`, seeds 1..40 | 40 of 40 pass | | Without the rename fix | FAT16 | `-n 4`, seeds 1..40 | 24 of 40 panic with `rename: lost dir entry` | Merged into `ffs-perf`; the msdosfs sources there are the ones that were tested. msdosfs is not yet turned on in the shipped i386 kernel config. Not tested: executing or mmap-ing files on msdosfs, since msdosfs never sets up per-file VM info and its mmap entry returns an error.

gitea-mirror commented

2026-11-03 22:03:03 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 15, 2026):

Follow-up from the stress suite phase 3 (stress-fs rename/link, branch stress-phase3):

An early version of the new rename test (workers rm -rf the shared tree while others still rename in it) panicked the v2 image's own kernel (pre-fix, built 2026-10-10) with free vnode isn't: v_type = 8, v_usecount = -1 — the panic listed above.
The same race on a kernel with these fixes (the issue-43 kernel, which contains 9db81ac41, 690848e2b, b2381210b and 89e39d0b2): 10 runs plus ~560 restarts over 10×60 s of rm -rf against stress-fs rename, and tree seeds 1-20 plus rename link seeds 1-10 on both the root fs and a UFS scratch disk — no panic, no hang, fsck clean.
ext2fs ran the same loads clean too. The run did find new bugs on other filesystems: #52 (ext2fs truncate panic, mmap), #53 (HFS lookup/rename deadlock), #54 (msdosfs rename deadlock, in the relookups added by 89e39d0b2), #55 (msdosfs mmap size loss).

@raynorpat commented on GitHub (Oct 15, 2026): Follow-up from the stress suite phase 3 (`stress-fs rename`/`link`, branch `stress-phase3`): - An early version of the new `rename` test (workers `rm -rf` the shared tree while others still rename in it) panicked the v2 image's own kernel (pre-fix, built 2026-10-10) with `free vnode isn't: v_type = 8, v_usecount = -1` — the panic listed above. - The same race on a kernel with these fixes (the issue-43 kernel, which contains 9db81ac41, 690848e2b, b2381210b and 89e39d0b2): 10 runs plus ~560 restarts over 10×60 s of rm -rf against `stress-fs rename`, and `tree` seeds 1-20 plus `rename link` seeds 1-10 on both the root fs and a UFS scratch disk — no panic, no hang, fsck clean. - ext2fs ran the same loads clean too. The run did find new bugs on other filesystems: #52 (ext2fs truncate panic, mmap), #53 (HFS lookup/rename deadlock), #54 (msdosfs rename deadlock, in the relookups added by 89e39d0b2), #55 (msdosfs mmap size loss).