Flaky: fork_exit_defer_reclaim_pairing_test intermittent per-PID reclaim-proof failure (pre-existing, aarch64)

[ryanbreen]

Summary

fork_exit_defer_reclaim_pairing_test fails intermittently in the aarch64 boot-test suite.

Reproduction (A/B Controlled Measurement)

• main branch: 1/10 runs fail with message per-PID defer/reclaim count pairing failed for a pairing-test child
• P2 branch (teardown-unification): 3/10 runs fail with message adapted-site per-PID reclaim proof was absent

Characteristics

• Pre-existing: Fails on unmodified main — not introduced by teardown-unification work
• Serial position: Both failure modes occur at the SAME position in kernel output (immediately after workqueue_operational:PASS, before the retirement-fence gate)
• No panic/fault markers: No DATA_ABORT, UAF, or panic markers in any failing run
• No data corruption signal: Failures are clean per-PID pairing/proof mismatches, not hardware exceptions

Required Investigation

This requires GDB-driven RCA per the project's mandatory debugging rules (kernel/src/task defer/reclaim pairing scheduler path). Log statements are forbidden in scheduler paths to avoid changing timing behavior.

Use the tracing framework and GDB breakpoints to:

1. Verify per-PID defer/reclaim count integrity during the test
2. Examine the timing window between fork exit and reclaim proof collection
3. Check for lost or missed pairing events under concurrent workqueue load

Context

• Tracked separately from teardown-phase work
• Blocks confidence in reclaim-pairing guarantees for P1 shutdown sequences
• Candidate for isolation: may represent a pre-existing race in defer/reclaim synchronization

Labels

bug