DF-3337 baseline (STOCK pf.ko, unpatched) — concurrent arm
============================================================
Provenance: captured live from the guest session of 2026-09-11 (serial
console + ssh transcript excerpts; the guest was reset afterwards for
the fix build, so this is the session record of /tmp/race_main.log and
/tmp/race_hot.log plus dmesg).

SESSION 1 — W=12 N=256 R=4 (race_main.log):

  flooding: 12 workers x 256 sources x 2 conns x 4 rounds ...
  round 0: WALK=   68608 expected=68608 MISSING=0
  round 1: WALK=   68608 expected=68608 MISSING=0
  round 2: WALK=       0 expected=68608 MISSING=68608
  round 3: WALK=   68608 expected=68608 MISSING=0
  TOTAL MISSING ENTRIES OVER 4 ROUNDS: 68608

  -> round 2's `pfctl -t hit -T show` returned ZERO rows: the kernel
     refused the walk and printed (dmesg, same session):
         pfr_get_addrs: corruption detected (-1).
     That is pf_table.c:586-590: the radix walk reached MORE nodes than
     pfrkt_cnt recorded (-1 = one callback beyond the counted set).

SESSION 2 (hot) — W=12 N=256 R=8 (race_hot.log, same binary, same
parameters, fresh pf state; run left running during analysis):

  flooding: 12 workers x 256 sources x 2 conns x 8 rounds ...
  pfr_get_addrs: corruption detected (-1).
  round 0: WALK=   65708 expected=68608 MISSING=2900
  (run degraded afterwards: flooders still active >5 min, packet rate
   collapsed -- same degradation the first big run showed:
   `pfctl -si` -> searches 690985 @ 650/s, inserts 10.5/s,
   synproxy 340430 events, load ~2.2, 12 workers never finishing;
   table count also CHANGED between two consecutive walks with no
   deletion: 65935 -> 65882.)

CONTROL — sequential arm (W=1, N=16, same binary, stock pf.ko):

  flooding: 1 workers x 16 sources x 2 conns x 1 rounds ...
  round 0: WALK=   65552 expected=65552 MISSING=0
  TOTAL MISSING ENTRIES OVER 1 ROUNDS: 0
  blocking-address kernel prints: 47   (every source fired >=1 overload)

  -> With the SAME binary and firing guarantee, single-threaded flood
     loses NOTHING; only concurrency produces loss/corruption.

EARLIER EXPLORATORY RUNS (NCONN=2, firing only ~6% of sources due to
per-CPU src-node thresholds — kept for the throughput-collapse record):
  12 workers x 256 x 2 x 8 rounds: round 0 WALK=65935/68608 MISSING=2673,
  then flooders never completed within 700s (rate collapse), state
  searches at 650/s.