DF-2623 console evidence (verbatim from the QEMU serial console)

=== [A] STOCK kernel #0 -- RW mount of craft2623.img (PFSROOT bit cleared
    on the testvol PFS inode bref) ===

hammer2_mount: devstr="/dev/vn0@testvol"
hammer2_mount: device="/dev/vn0" label="testvol" rdonly=0
hammer2_ondisk: "/dev/vn0" zone=0 id=0 offset=0x0000000000000000 size=0x0000000004000000
hammer2_mount: "/dev/vn0": no recovery needed
hammer2: Correct mis-flagged PFS testvol
hammer2_mount: hmp=0xfffff801192e4000 pmp=0xfffff801185a2000

# The kprintf at vfsops.c:2405-2406 ran and printed ripdata->filename.
# Second mount of the same image: no message (the fixup re-set the flag
# and flushed it during the first mount).

=== [B] INSTRUMENTED kernel #1 -- freshly re-forged image, same mount ===

DF2623: ripdata=0xfffff80051cc6800 vs chain->data=0xfffff80051cc7000 (same=0) name-by-old-ptr="testvol" name-by-new-ptr="testvol"
hammer2: Correct mis-flagged PFS testvol

# PROOF: at kprintf time ripdata (captured at vfsops.c:2399 BEFORE
# hammer2_chain_modify) no longer equals &chain->data->ipdata -- the
# modify COW'd the inode to a new media block (new data_off, chain.c:
# 1797 io_bread / 1827 bcopy / 1858 hammer2_io_bqrelse(&tio) releasing
# the chain's reference on the OLD dio) and chain->data was redirected
# (chain.c:1859).  The kprintf therefore reads the filename through a
# pointer into the RELEASED old buffer.  On this run the COW landed in
# the same 64KB window (0x...6800 vs 0x...7000) and the released
# buffer still holds the copied bytes, so the printed name is intact --
# the read-after-release is real, observable stale CONTENT was not
# produced (bqrelse retains cached contents; no I/O lands in the
# sub-microsecond window between the release at :1858 and the kprintf).

=== [C] FIX kernel #2 -- same freshly re-forged image ===

hammer2: Correct mis-flagged PFS testvol

# kprintf now sources chain->data->ipdata.filename (post-COW, always
# valid); message identical, semantics of the fixup unchanged.