DF-3096 — mount -u ronly→rw: RW internal state and media writes are not rolled back when stage2 recovery fails

Target: sys/vfs/hammer/hammer_vfsops.c:475-509 (the MNT_UPDATE transition), interacting with sys/kern/vfs_syscalls.c:399-410 (flag rollback) and sys/vfs/hammer/hammer_recover.c:1427-1467 (media write of the recovered volume header).

Mechanism (all lines verified against the audit tree)

hammer_vfs_mount() MNT_UPDATE ronly→rw path:

478:    if (hmp->ronly && (mp->mnt_kern_flag & MNTK_WANTRDWR)) {
479:        hkprintf("read-only -> read-write\n");
480:        hmp->ronly = 0;         /* (a) cleared FIRST */
481:        RB_SCAN(... hammer_adjust_volume_mode, NULL);   /* (b) devices reopened FWRITE */
483:        rootvol = hammer_get_root_volume(hmp, &error);
484:        if (rootvol) {
485:            hammer_recover_flush_buffers(hmp, rootvol, 1); /* (c) recovered root vol header WRITTEN TO MEDIA */
486:            error = hammer_recover_stage2(hmp, rootvol);  /* (d) may FAIL */
487:            bcopy(rootvol->ondisk->vol0_blockmap, hmp->blockmap, ...);
490:            hammer_rel_volume(rootvol, 0);
491:        }
...
508:        lwkt_reltoken(&hmp->fs_token);
509:        return(error);          /* (e) error returned, NO state rollback */

• (c) with final=1 flushes the stage1-recovered root volume header to media: hammer_recover_flush_buffers() → hammer_io_flush(&root_volume->io, 0) (hammer_recover.c:1460-1466) — the write happens before stage2 is known to succeed.
• (d) hammer_recover_stage2 fails on corrupt undo/blockmap data (e.g. the "Undo size is absurd" EIO at hammer_recover.c:~610, or REDO-term scan errors).
• (e) the error propagates to sys_mount(), which rolls back only the flags: mp->mnt_flag = flag; mp->mnt_kern_flag = flag2; (vfs_syscalls.c:405-408) — restoring MNT_RDONLY on the mount — while hmp->ronly stays 0 and every device vnode stays open read-write.

Consequences on the still-mounted, RO-presenting filesystem

1. hammer_get_inode() stamps HAMMER_INODE_RO only if (hmp->ronly) (hammer_inode.c:469-470) — new inodes are created writable.
2. Every HAMMER ioctl that gates on hmp->ronly (mirror-write, prune, reblock, dedup, snapshot ops — hammer_ioctl.c) is write-enabled on a mount the administrator believes is read-only after seeing the failed mount -u.
3. The flusher runs in RW mode against the FWRITE-opened devices.
4. Media state: the recovered volume header was already rewritten (half-applied recovery) even though mount reported failure — the filesystem on disk is mutated by a mount operation that "failed".

Threat model

Privileged: requires mount -u -o rw (root) on a filesystem whose stage2 recovery fails — corrupt/crafted media (post-incident forensics scenario: mount -o ro succeeds, the subsequent RW update attempt fails halfway) or a device developing I/O errors mid-recovery. The resulting state misleads the operator and enables writes into a half-recovered filesystem.

Why Phase V was not executed (status: untested)

Triggering requires an image that passes stage1 at RO mount but fails stage2 at the update — stage2's reachable error returns sit behind REDO_SYNC-record state ("Undo size is absurd" only fires when stage1 found REDO records; term-scan errors need crafted REDO chains), which makes a deterministic crafted image a research project of its own (DF-3067/3068-era crafts fail at stage1 or panic instead). The state machine itself is fully code-proven above. Risk/effort for a Medium, root-triggered integrity bug was judged disproportionate this run.

Suggested fix

--- a/sys/vfs/hammer/hammer_vfsops.c
+++ b/sys/vfs/hammer/hammer_vfsops.c
@@ rootvol = hammer_get_root_volume(hmp, &error);
        if (rootvol) {
            hammer_recover_flush_buffers(hmp, rootvol, 1);
            error = hammer_recover_stage2(hmp, rootvol);
+           if (error) {
+               /* roll the RW transition back */
+               hmp->ronly = 1;
+               RB_SCAN(hammer_vol_rb_tree, &hmp->rb_vols_root,
+                   NULL, hammer_adjust_volume_mode, NULL);
+           }
            bcopy(rootvol->ondisk->vol0_blockmap, hmp->blockmap,
                  sizeof(hmp->blockmap));

(the bcopy after a failed stage2 should also be dropped — the blockmap of a failed recovery must not replace the live one).

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.)