DF-3170 — second stock-kernel manifestation (producer side), 2026-09-07 ~15:56 UTC.

Same 6-writer unprivileged stress as run #1 (mfs mounted at /mnt/mfs,
/dev/mfs853, server pid 853, writers pids 865-875), running for <90 s while
an unrelated root devfs mount/open/umount sequence executed. Serial console
(two CPUs panic simultaneously; character-interleaved first line, raw form
preserved in run2_panic_serial.log):

    panic: Bad tailq NEXT(0xfffff8001f7ffbf8->tqh_last) != NULL, last 0xfffff8004f49c9a0
    cpuid = 2
    Trace beginning at frame 0xfffff801185933e8
    mfsstrategy() at mfsstrategy+0x128 0xffffffff809133a8
    mfsstrategy() at mfsstrategy+0x128 0xffffffff809133a8
    dev_dstrategy_chain() at dev_dstrategy_chain+0xc7 0xffffffff8062d367
    devfs_spec_strategy() at devfs_spec_strategy+0xfb 0xffffffff80922fab
    vop_strategy() at vop_strategy+0x58 0xffffffff8070b578
    ufs_strategy() at ufs_strategy+0x5a 0xffffffff80917c8a
    Debugger("panic")
    CPU2 stopping CPUs: 0x0000003b

"Bad tailq NEXT(%p->tqh_last) != NULL" is QMD_TAILQ_CHECK_TAIL
(sys/sys/queue.h:514-519), the INVARIANTS check inside TAILQ_INSERT_TAIL —
this is the PRODUCER (mfsstrategy, from unprivileged file I/O via
ufs_strategy) observing the queue tail corrupted by the racing consumer
(mfs_start) — the mirror image of run #1's consumer-side
"Bad link elm prev->next != elm" panic from mfs_start.

ATTRIBUTION NOTE (honesty record): this panic was initially attributed to
DF-3171 (a hypothesized VRECLAIMED-close teardown kill). That attribution
was WRONG: the root devfs sequence in flight at the time could not have
fired any d_close (the FWRITE open of the mounted device returns EBUSY at
devfs_vnops.c:1006-1020, and a read-only fd's open migrates to the primary
devfs vnode, leaving the second-devfs vnode with no open count for vclean
to force-close). The writers' ongoing race is the sufficient and complete
explanation — see the DF-3171 pack's investigation record.