DF-3181 — failed non-forced umount of tmpfs has already truncated every file (destructive side effect before vflush)

What

tmpfs_unmount (sys/vfs/tmpfs/tmpfs_vfsops.c:284-334) walks every node and calls tmpfs_truncate(vp, 0) on all VREG files before vflush(mp, 0, flags). If vflush then fails (vnode still referenced → EBUSY), unmount returns the error and the filesystem remains mounted — with every file's contents already destroyed:

    /*
     * Flush all vnodes on the unmount.
     *
     * If we fail to flush, we cannot unmount, but all the nodes have
     * already been truncated. Erroring out is the best we can do.
     */
    error = vflush(mp, 0, flags);
    if (error != 0) {
        TMPFS_UNLOCK(tmp);
        return (error);
    }

The correct order is to run vflush first (which can fail harmlessly) and only discard data once vflush has succeeded (or for MNT_FORCE).

Trigger surface (measured on the guest)

In practice the window is narrower than it looks: dounmount (sys/kern/vfs_syscalls.c) bails out with EBUSY at its mnt_refs retry loop before VFS_UNMOUNT is ever called whenever an open fd's f_nchandle still references the mount — an open file (even unlinked) keeps a namecache/mount reference and shields the filesystem from tmpfs_unmount entirely (demonstrated: two attempts, no truncation, see run.log / run2.log). The truncation-then-EBUSY path requires a vnode that is v_usecount-busy with no f_nchandle — e.g. a vnode pinned by an in-flight VOP on another CPU racing dounmount, or other transient kernel holds. Hence: not reproduced from a stable userspace state; the code order is still unconditionally wrong and destructive whenever vflush fails.

Reproduce attempt

run.sh    # mounts tmpfs, writes 4MB file, holder opens+unlinks it and
          # fstat()s every second, then `umount` (non-forced)

Observed: umount: Device busy, mount stays, holder's fd never shrinks (dounmount early EBUSY shield) — see run.log/run2.log.

Fix

Move the destructive truncate loop after a successful vflush (or behind if (error == 0)), leaving data intact whenever the unmount fails; for MNT_FORCE the truncation before FORCECLOSE vflush is intentional and can stay behind if (flags & FORCECLOSE).

DF-3181 verdict — NOT REPRODUCED from a stable state (window shielded by dounmount's mnt_refs loop); defect confirmed by code order

Attempts (stock INVARIANTS guest): 1. mount tmpfs /mnt/df3181 + 4MB file + sleep 300 <file holder (fd open, namecache entry present) + umount → EBUSY, file NOT truncated (4194304 bytes intact). dounmount returned EBUSY before reaching VFS_UNMOUNT because the file's namecache entry holds a mount ref. 2. Same, but holder opens the file and UNLINKS it (no namecache entry, only the fd) + umount → EBUSY again, file still 4194304 bytes after 16 s of polling. The open fd's fp->f_nchandle still pins the mount: dounmount's mnt_refs retry loop (kern/vfs_syscalls.c dounmount) again shields tmpfs_unmount from running at all.

Conclusion: with purely userspace-held references, dounmount fails early and tmpfs_unmount's destructive order is never exercised. The truncate-before-vflush window requires a vnode that is busy (v_usecount > 0) without an f_nchandle/mount ref — in-flight VOP on another CPU, transient kernel holds — i.e. a race, or paths not exercised here.

The code-order defect is real and unambiguous (tmpfs_vfsops.c:284-334: tmpfs_truncate(vp, 0) for every VREG node precedes vflush(mp, 0, flags) whose failure leaves the mount alive), and the author's own comment acknowledges the data loss ("all the nodes have already been truncated. Erroring out is the best we can do."). Filed Low: data-destruction on a failed operation, practical trigger narrow (race).

Status: not_reproduced / impact=none (in these attempts) / confidence likely that the order is wrong, speculative for practical triggerability.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.

(No fix.diff for this item: documented recommendation only - see Fix above.)