aarch64 has no gate that runs TEST_BINARIES userspace tests (--features testing is built by no committed aarch64 gate)

[ryanbreen]

Problem

No committed aarch64 gate script builds --features testing, so
kernel::boot::test_list::TEST_BINARIES entries -- userspace test
binaries loaded via load_test_binaries_from_ext2() -- run in zero
aarch64 gates today, independent of any runtime bugs in the profile
itself (claim-lint:ok: 0 of 5 committed aarch64 gate scripts build
testing; see the exact grep and 5-way breakdown below).

load_test_binaries_from_ext2() is #[cfg(feature = "testing")]
(kernel/src/main_aarch64.rs:1362, function body at :1471). All 5
committed aarch64 scripts were checked this round
(grep -n -- "--features" docker/qemu/run-aarch64-*.sh, re-run this
round; claim-lint:ok: 5 of 5 scripts enumerated by name in the 3 bullets
below):

• docker/qemu/run-aarch64-service-sequence-gate.sh:116 and
  docker/qemu/run-aarch64-full-test.sh:55 build --features boot_tests
  (2 of 5).
• docker/qemu/run-aarch64-boot-test-native.sh,
  docker/qemu/run-aarch64-boot-test-strict.sh, and
  docker/qemu/run-aarch64-prod-profile-boot-test.sh:140 build with no
  --features at all (3 of 5; the last one's own comment says the
  absence is deliberate).
• docker/qemu/run-aarch64-test-suite.sh:131 is the one committed script
  that does build --features testing, but it is not a gate (no
  PASS/FAIL verdict, no allowlist) and would not exercise this wiring
  either -- it rewrites kernel/src/main_aarch64.rs per test to
  substitute a per-test launch hook and never touches TEST_BINARIES or
  load_test_binaries_from_ext2() (claim-lint:ok: the script's own
  comment at docker/qemu/run-aarch64-test-suite.sh:103-107 says so
  directly -- "the testing profile loads the whole
  boot::test_list::TEST_BINARIES roster through
  load_test_binaries_from_ext2, so this script cannot select a single
  test" -- and also discloses its own rewrite target,
  run_userspace_from_ext2, "no longer exists anywhere under kernel/",
  i.e. this script is currently a no-op on this tree, separately from
  the TEST_BINARIES gap).

0 of the 5 builds testing in gate form (claim-lint:ok: 0 of 5, per the
3-bullet breakdown above), so load_test_binaries_from_ext2() is
compiled out (claim-lint:ok: 5 of 5, same breakdown).

Affected tests

Both currently zero-coverage on aarch64, for this reason:

• tcp_cloexec_exec_test -- added to TEST_BINARIES at
  kernel/src/boot/test_list.rs:108 (branch fix/707-cloexec-tcp-test,
  the close_cloexec() leaks TcpConnection/TcpListener across exec() -- no tcp_close/tcp_listener_ref_dec #707 regression test).
• tcp_dup_listener_test -- x86/aarch64: sys_close() leaks TcpListener refcount -- log-only, never calls tcp_listener_ref_dec #724's sibling test. Checked this round:
  0 of 15 committed files carrying its own TCP_DUP_LISTENER_* marker
  are aarch64-pathed (grep -rl TCP_DUP_LISTENER docs/ docker/, then
  filtered for aarch64 in the path); the only 3 aarch64-pathed files
  that mention the bare name tcp_dup_listener_test at all are ext2
  install/directory listings showing the binary present on disk, not
  execution evidence (checked directly: each hit is an
  Installed tcp_dup_listener_test.elf build line or an ls -l-style
  directory entry, 0 PASSED/FAILED marker lines among them).

Any other TEST_BINARIES entry shares the same #[cfg(feature = "testing")] gate and so has the identical exposure; these two are the
ones this round's own work surfaced directly.

Relationship to #562 / #761

#562 (softirq self-test panics before userspace) and #761 (loader hangs
after bypassing #562) are runtime blockers: they currently stop the
--features testing aarch64 profile from booting far enough to reach a
userspace test verdict at all. This issue is a different, structural
problem that sits behind those two: even after both are fixed, no
committed aarch64 gate would build the profile that runs these tests in
the first place. Fixing #562 and #761 is necessary but not sufficient to
close this gap.

Smallest proposed fix

A new aarch64 gate script (or an addition to an existing one, if one
already builds testing for another reason after #562/#761 land) that:

1. Builds kernel-aarch64 with --features testing on the soft-float
   target (aarch64-breenix-kernel.json), matching the guard other
   aarch64 gates already carry against the NEON hardfloat target
   (scripts/check-kernel-no-neon.sh).
2. Boots it against an ext2 disk containing the TEST_BINARIES roster.
3. Asserts that each entry in kernel::boot::test_list::TEST_BINARIES
   emitted its own pass marker (that test's own
   *_PASSED/*_FAILED convention), not just that the boot reached a
   shell prompt -- mirroring the marker-driven verdict shape
   x86-gate-verdict.sh already uses on x86, rather than
   run-aarch64-test-suite.sh's per-test kernel-rewrite approach.

Not building the gate as part of this issue -- filed to make the gap
explicit and trackable; a real fix is a dedicated gate-authoring round.

[ryanbreen]

Correction to the gate census above (review-707.md finding F5,
fix/707-cloexec-tcp-test round 3): this issue's own quoted command,
grep -n -- "--features" docker/qemu/run-aarch64-*.sh, does not return 5
scripts. Re-run this round:

$ ls docker/qemu/run-aarch64-*.sh | wc -l
16
$ grep -n -- "--features" docker/qemu/run-aarch64-*.sh | cut -d: -f1 | sort -u | wc -l
9

The glob matches 16 scripts, and 9 of them contain --features,
not 5. Four gate scripts were missing from the original 3-bullet
breakdown:

• run-aarch64-refusal-drain-gate.sh:45 -- builds --features boot_tests,resume_pc_foreign_oracle.
• run-aarch64-percpu-stack-custody-gate.sh:68 -- builds --features boot_tests,percpu_stack_custody_oracle.
• run-aarch64-tty-oracle-gate.sh:109 -- builds with no --features,
  deliberately (per its own comment, same convention as
  -prod-profile-boot-test.sh).
• run-aarch64-arma609-arm.sh -- mentions --features arm_a_609 /
  boot_tests only inside error-path echo suggestions; it does not
  build itself, requires a prebuilt --features arm_a_609 kernel, and
  refuses any other.

Separately, run-aarch64-boot-test-strict.sh is mischaracterized in the
original breakdown ("build[s] with no --features at all," grouped with
-native.sh and -prod-profile-boot-test.sh). It builds nothing -- 0
of 2 cargo build mentions in the file execute
(grep 'cargo build' docker/qemu/run-aarch64-boot-test-strict.sh | grep -vc echo -> 0); both are echo suggestions. It is the strict
kernel-merge gate ("Used for CI to catch regressions," per its own header
comment) and it refuses any kernel that is not --features boot_tests, via a 7-marker literal census in require_boot_tests_kernel()
at docker/qemu/run-aarch64-boot-test-strict.sh:78-99 that exits 1 on a
miss -- the opposite of "builds with no --features."

The conclusion this issue draws is unaffected: 0 of 9 named scripts
build --features testing in gate form, except
run-aarch64-test-suite.sh:131, which this issue already correctly
identifies as not a gate. But "0 of 5" understated the census, and "add
testing to the 5 gates" would have missed 4 more -- the same
closed-name-list failure mode this campaign has hit before (#549, #551,
#527-r1). Leaving the issue body as originally filed and posting this as
a correction rather than a silent edit.

[ryanbreen]

slice-3b-landed

Merged via PR #807, merge SHA 20a73d8a27afec2c911d9838381f17c41e36a514. The
testing-profile gate script (docker/qemu/run-aarch64-testing-profile-boot-test.sh)
and its classifier ratchet (tests/aarch64_testing_profile_structure.rs) are on
main.

Baseline red, as classified: #562 (10 of 12 boots, ksoftirqd panic) and #803
(2 of 12 boots, pre-panic stall — filed as its own bucket with a committed
specimen). Promotion of this script to a merge gate is slice 3m.

[ryanbreen]

Reopening. This issue was auto-closed by GitHub, not by a fix.

Merge commit e6dd14a (landed via PR #808) quoted the auto-close vocabulary
while rewording it away: its own message body reads "clos<e> #763" as
literal text describing what it was rewriting in
SLICE3-PLAN-2026-09-05.md, and GitHub's parser does not distinguish a
close keyword inside a description from one used to close. The keyword sat
directly in front of #763 in a commit on the default branch, so it fired
on merge.

True state: this issue has two halves, and only one has landed. PR #807
landed the structural half — the first committed aarch64 gate script that
builds --features testing (docker/qemu/run-aarch64-testing-profile-boot-test.sh)
plus its classifier's structure tests. The behavioural half (the two
underlying defects, #562 and #761, fixed by slices 3f and 3g) and the
promotion of that script into an actual merge gate (slice 3m) are still
open, per
docs/planning/green-program/aarch64-testing/SLICE3-PLAN-2026-09-05.md. The
gate is not wired into any merge path today: grep -rn run-aarch64-testing-profile-boot-test docker scripts matches only the
script itself.

reopen-e6dd14a6