# Diagnostic v3 review — 2026-09-27

Checked the local generator and remote generated kernel/axp_diag_capture.c,
attempt 20260927T084106Z, while plain-v3 was building. No build cancellation,
source modification on the server, or device operations were performed.

## Corrected

- Failure handler no longer maps memory.
- Event claim uses atomic_cmpxchg before composing the record.
- Event path checks a previous persistent AXPDIAG1 header.
- Milestone prefix length excludes the terminating NUL.
- Explicit byte I/O replaces memcpy on the MMIO writer path.
- Early mapping now precedes parse_early_param in ARM64 setup_arch.

## Blocking issue: permanent mapping before allocators exist

The new setup.c hook at lines 398–402 calls axp_diag_map_permanent immediately
after paging_init. This is still inside setup_arch, before start_kernel calls
mm_init. It even precedes bootmem_init in setup_arch.

axp_diag_map_permanent releases the early map and calls ordinary ioremap.
In this tree, arch/arm64/mm/ioremap.c calls get_vm_area_caller, which reaches
mm/vmalloc.c:1405 __get_vm_area_node and kzalloc_node at line 1421, followed by
alloc_vmap_area. The allocator initialization (mem_init, kmem_cache_init,
vmalloc_init) occurs later in init/main.c:mm_init.

Thus paging_init is NOT the readiness gate for ordinary ioremap. This diagnostic
can introduce its own boot failure in the no-FORTIFY control. Do not use a
failure of this control to draw conclusions about FORTIFY.

The transition needs a deliberate lifetime plan: ordinary mapping only after
its allocators are ready, and safe retirement of the early mapping respecting
early_ioremap_reset. Simply relocating one call without checking that lifetime
is insufficient. If a temporary uncovered interval is chosen, document it and
ensure failure writers cannot dereference a stale early mapping.

## Mapping attributes and persistence

early_memremap uses FIXMAP_PAGE_NORMAL, whereas the permanent ioremap and
access-ramoops use PROT_DEVICE_nGnRE. This changes memory attributes. The writer
only uses wmb and a readback; it has no explicit cache maintenance for a cached
early mapping. These operations alone do not establish that early cached writes
reach reset-surviving memory. Review compatible early I/O mapping attributes
(early_ioremap uses FIXMAP_PAGE_IO in this tree) and verify on hardware.

## Remaining first-record limitations

- Milestones check the latch but do not participate in its atomic claim. A
  milestone interrupted by a failure writer can resume and overwrite the same
  slots. Separate milestone storage from first-failure storage, or use a
  protocol that also covers milestones and reentrancy.
- A bare eight-byte header is treated as a complete prior failure. An interrupted
  write that persisted only that header can suppress later captures. Validate a
  complete record/commit indication and inspect mirrors.
- The identifier remains per build, not per boot; archive/clear old captures
  under an explicit test procedure before repeating the same image.

The improvements are real, but v3 is not yet ready to be described as a
validated early-capture channel. These findings concern instrumentation, not an
identified cause of the original FORTIFY boot failure.

## Status

Local generator updated to **v4**: no `ioremap` until after `mm_init`; early
map uses `early_ioremap` (IO attrs) and is kept until then; failure @0 vs
milestones @2048; adopt only complete records. plain-v3 must not be flashed —
rebuild control as plain-v4.