# DF-3215 — HAMMER1 UNDO/REDO FIFO exhaustion panic in hammer_generate_redo

## What

`hammer_generate_redo()` (sys/vfs/hammer/hammer_redo.c:90-91) panics the
kernel when the UNDO/REDO FIFO has less than `len + 48KB` free:

```c
	if (hammer_undo_space(trans) < len + HAMMER_BUFSIZE*3)
		hpanic("insufficient UNDO/REDO FIFO space for redo!");
```

There is **no waiting/throttling path** for REDO generation.  The frontend
`write()` lays REDO records (with full data payloads) into the FIFO at
memory speed under `undo_lock`; space is reclaimed only when the flusher
completes a full finalize cycle, and the **on-disk** `first_offset` that
governs `hammer_undo_space()` (hammer_undo.c:477-498) lags at least one
full cycle behind (hammer_flusher.c:793-836).  Default
`vfs.hammer.fsync_mode = 3` (hammer_vfsops.c:100) makes `fsync()` take the
REDO fast path, which resets the 4MB per-inode REDO budget
(hammer_vnops.c:239) forever — so an unprivileged `write()+fsync()` loop
lays unbounded REDO records between reclaims.

The trailing REDO_SYNC emission (hammer_redo.c:288-291) runs *after* the
main record has been laid and `next_offset` advanced, so the panic can
fire there even when the caller's own record fit.

## Reproduce (on the audit guest)

```sh
# one-time setup (root): HAMMER1 fs with the minimum 8MB UNDO/REDO FIFO
# (newfs_hammer -f -u 8m — a supported configuration; mkhammer only warns)
sh /tmp/df3215/setup_v2.sh        # vn0 image + newfs_hammer + mount /mnt/h1

# trigger (unprivileged):
su -m nobody -c "/tmp/df3215/redo_fill /mnt/h1/scratch 1 1048576 30"
```

## Expected output (stock kernel, unprivileged)

Guest panics after ~6 rounds (~6MB of REDO records into the 8MB FIFO):

```
panic: hammer_generate_redo: insufficient UNDO/REDO FIFO space for redo!
hammer_generate_redo() at hammer_generate_redo+0x575
hammer_generate_redo() at hammer_generate_redo+0x575   <- trailing SYNC emit
hammer_vop_write() at hammer_vop_write+0x675
vn_write() -> kern_pwritev()
```

SSH dies, guest sits in ddb.  See `panic.txt`, `run_v2.log`.

## Scope / variants

- V2 (deterministic, reproduced): 8MB FIFO (newfs_hammer minimum with -f).
- V1 (default 512MB FIFO): NOT reproduced on the QEMU guest — the
  page-cached virtio flusher reclaimed fast enough (3.84GB of REDO laid,
  no overflow).  On real (especially spinning) storage the same race
  window exists, but that claim is not demonstrated here.

## Fix

`fix.diff` replaces the hpanic with a graceful `ENOSPC` failure and adds a
FIFO-pressure gate to the write path that disables REDO (the existing
degradation idiom) until space returns.  Validated: patched kernel does
not panic; writes succeed with REDO disabled; mount stays healthy.