loopback_wake_test fails (child killed with signal 15, parent exits 1) on beast KVM x86 when a second concurrent loopback-TCP workload is present

[ryanbreen]

Summary

On the beast breenix-x86 KVM host, the testing,external_test_bins profile
intermittently reports

TEST_TALLY: exited=21 nonzero=2 failed=[loopback_wake_test_child:15,loopback_wake_test:1]

One of loopback_wake_test's children is killed with signal 15 and the
parent exits 1. scripts/x86-gate-verdict.sh fails the boot, correctly — the
allowlist is empty.

The parent's other children exit cleanly on the same boot:

Process 16 'loopback_wake_test_child_16' (thread 26) exited with code 15
Process 19 'loopback_wake_test_child_19' (thread 31) exited with code 0
Process 20 'loopback_wake_test_child_20' (thread 33) exited with code 0
Process 12 'loopback_wake_test'          (thread 22) exited with code 1

so one child of several is being torn down while its siblings are fine.

Serials

Preserved in-repo, one from each arm of an A/B battery:

• docs/planning/green-program/sockets/serials/x86-loopback-red-armA-reorder-out-kernel-20260829.txt
• docs/planning/green-program/sockets/serials/x86-loopback-red-armB-reorder-in-kernel-20260829.txt

The tally line is byte-identical in both.

Rate

Measured on beast breenix-x86, KVM, -cpu host, sequential boots, identical
build flags, three arms differing only in the kernel tree:

arm	tree	boots	loopback red
A	fix/568-poll-wedge (scheduler.rs identical to main)	8	1
B	same + a Scheduler::schedule() reordering hunk	8	2
M	pristine main @ 6d0d2ac5	8	0

What this rules in and out

It is not the scheduler reordering the #568 branch was carrying: the red
appears on both sides of the A/B with the same signature, so the hunk neither
causes nor prevents it. That hunk has since been reverted.

It is correlated with the added workload, not with a kernel change. The
only kernel difference between arm A and main is #568's sys_poll halt repair
(two hand-inlined halts replaced by the shared arch_halt_with_interrupts()
primitive). What arm A also adds is a userspace program: a second concurrent
loopback-TCP connection on port 9568 plus a fork(), running on every boot.
3/16 against 0/8 is suggestive, not conclusive, and the honest reading is that
the branch's extra loopback traffic makes an existing weakness in the loopback
wake path more likely to surface — not that it introduces one.

No fault is involved. No panic and no page-fault record appears in any of
the 24 boots across the three arms.

Where to start

The signal-15 teardown of one child while its siblings survive is the specific
thing to explain: who sends it, and why only under a concurrent second loopback
connection. loopback_wake_test and the loopback wake path itself
(#570 kloopbackd, and the pump structure test that pins its shape) are the
adjacent history.

Found while re-doing #568's evidence (green program, sockets); full A/B in
docs/planning/green-program/sockets/EVIDENCE-2026-08-29.md §5.

[ryanbreen]

Fresh rate at the merge candidate — still open, and round 3 does not attribute it

Measured on beast breenix-x86 (KVM, -cpu host,
testing,external_test_bins, BREENIX_NET_MODE=none) at kernel commit
efe08b17, in an interleaved A/B whose two arms differ only by
kernel/src/task/scheduler.rs:

	reorder IN (merge candidate)	reorder reverted
boots	24	16
loopback_wake_test_child:15, loopback_wake_test:1	9/24 (37.5%)	0/16
boots that emitted a TEST_TALLY at all	24/24	3/16

The 0/16 is censored and must not be read as an exoneration. The
reorder-reverted arm strands poll_tcp_oracle in 12 of its 16 boots, so those
runs never reach the tally line this red is read from. Conditioned on a tally
being emitted the comparison is 9/24 against 0/3, which discriminates
nothing (one-sided Fisher ~0.55).

So the better evidence remains round 2's uncensored three-arm battery — 1/8
reorder-out, 2/8 reorder-in, 0/8 pristine main, with a byte-identical tally
line on both sides of the reorder — which points at the branch's added
concurrent loopback-TCP workload rather than at any kernel change. Round 3
neither confirms nor refutes that; it only supplies a much larger rate at the
bytes that would merge.

Two observations that may help whoever picks this up:

• The failing tally is stable in shape across all nine occurrences —
  loopback_wake_test_child:15 (SIGTERM) plus loopback_wake_test:1, one child
  of several while its siblings exit 0.
• On three of the nine it coexists with a poll_tcp_oracle oracle FAIL in the
  same tally (exited=25 nonzero=3), so the two are not mutually exclusive.

Fresh serial in-repo:
docs/planning/green-program/sockets/serials/x86-r3-CAND-loopback-red-boot13-kernel-20260829.txt.
Per-boot table: docs/planning/green-program/sockets/AB-2026-08-29-round3.md.

Still live and still unallowlisted — on merge it reddens the x86 gate at ~37%,
with no entry in scripts/x86-gate-allowlist.txt. Leaving it open and
un-allowlisted is deliberate: allowlisting a red whose cause is unknown is how a
gate stops meaning anything.