DF-2668 decisive run (via `vm.sh run_root`):

    # df /tmp | tail -1
    tmpfs         1996544   16 1996528     0%    /tmp
    # mount -t null /tmp /tmp/nmtest
    # /tmp/df2668 /tmp/nmtest/anchor_file
    DF-2668: getfh(/tmp/nmtest/anchor_file) ok; fh_fsid = 89630026,0000000b
    <syscall never returns — guest freezes; ssh session times out>

Serial console (vm.sh log):

    panic: assertion "mp->mnt_refs == 0" failed in mount_drop at /usr/src/sys/kern/vfs_mount.c:402
    cpuid = 4
    Trace beginning at frame 0xfffff8011828b6e8
    mount_drop() at mount_drop+0x5d 0xffffffff806fa56d
    mount_drop() at mount_drop+0x5d 0xffffffff806fa56d
    sys_fhstatfs() at sys_fhstatfs+0xd4 0xffffffff80707464
    sys_xsyscall() at sys_xsyscall+0x89 0xffffffff80bd7039
    syscall2() at syscall2+0x11e 0xffffffff80bd6a0e
    Debugger("panic")

The lower mount here is the tmpfs backing /tmp; its mnt_hold went 1->0 via
the unmatched mount_drop() in sys_fhstatfs(), and mount_drop's
KKASSERT(mnt_refs == 0) fired because the live tmpfs still has topology
refs (mnt_refs >= 1). On a release kernel (no INVARIANTS) the same
execution path kfree()s the live struct mount instead — a use-after-free.