# DF-3480 run.log (decisive runs, reconstructed from the live session output)
## 240s race run (8 readers, flood paced 8-burst/200us, debug_level=1,
## listen+attach fixes applied so the handshake can reach OPEN; otherwise
## stock INVARIANTS guest kernel):

listener ready (psm 0x1234)
setup state=0
con_ind state=0
cfg_ind state=0
cfg state=0
accepting...
ACCEPTED fd=5 — child socket is OPEN; starting race
t+01 sent=35072 errs=0
t+02 sent=70376 errs=0
t+03 sent=105544 errs=0
...
t+238 sent=16757256 errs=0
t+239 sent=16792400 errs=0
t+240 sent=16827560 errs=0
reader done: 1 reads, 128 bytes
reader done: 0 reads, 0 bytes
reader done: 1 reads, 128 bytes
reader done: 0 reads, 0 bytes
reader done: 0 reads, 0 bytes
reader done: 0 reads, 0 bytes
reader done: 0 reads, 0 bytes
reader done: 0 reads, 0 bytes
DF-3478 run complete (no crash)

## 45s follow-up with the FIONREAD/drain probe:

t+45 sent=1545064 errs=0
reader done: 3 reads, 384 bytes
reader done: 1 reads, 128 bytes        (6 more readers: 1 read each / 0)
FIONREAD: 4352 bytes queued
post-race read -> 128
DF-3478 run complete (no crash)

## interpretation

16.8M packets were accepted by the btsock node in 240s (errs=0 throughout:
none dropped at the netgraph queue). The child's so_rcv saturates after ~34
records (64KiB recvbuf vs ~2KiB sb_mbcnt per cluster-backed record) and the
8 readers perform a total of NINE reads, then sleep for the rest of the run
while FIONREAD afterwards reports 4352 bytes queued and a fresh
select()+read() syscall successfully returns another record.

soreceive never blocks when sb_mb != NULL; readers sleeping while sb_cc
claims 25+ queued records means the append side (ng_btsocket_l2cap_data_input
-> sbappendrecord, executed on the taskqueue_swi thread holding only
pcb_lock/sockets_lock) and the consume side (soreceive on user threads under
so_rcv.ssb_token) mutated the sockbuf without any common lock — the
lost-wakeup/torn-tail signature of that race. No kernel memory corruption
was captured in ~10 minutes of racing (~2x10^7 accepted deliveries), so
memory-safety impact is NOT claimed as reproduced; the observable
manifestation is a permanently wedged socket (silent data loss + starved
readers).