# DF-4708 — amr_pci DMA setup: `goto retry` loop leaks the s/g table
# unboundedly and all three bus_dmamap_load results are ignored
# (failure yields 0 / garbage bus addresses handed to the controller)

## What
`sys/dev/raid/amr/amr_pci.c:592-603` — `amr_sglist_map()`:

```c
retry:
    error = bus_dmamem_alloc(sc->amr_sg_dmat, &p, BUS_DMA_NOWAIT,
                             &sc->amr_sg_dmamap);
    if (error) { ... return(ENOMEM); }
    bus_dmamap_load(sc->amr_sg_dmat, sc->amr_sg_dmamap, p, segsize,
                    amr_sglist_helper, &sc->amr_sgbusaddr, 0);   /* unchecked */
    if (sc->amr_sgbusaddr < 0x2000) {
        debug(1, "s/g table too low ...");
        goto retry;                       /* leaks p + the dmamap */
    }
```

1. The retry path (documented `XXX HACK ALERT`, amr_pci.c:586-591)
   leaks both the DMA memory **and** the dmamap of every rejected
   allocation — `sc->amr_sg_dmamap` is simply overwritten on the next
   iteration. The loop has **no bound**: if `bus_dmamap_load` fails
   (its return value is ignored, and `amr_sglist_helper`
   (amr_pci.c:533-541) also ignores its `error` argument and never
   writes the address), `sc->amr_sgbusaddr` stays 0 → `0 < 0x2000` →
   retry forever, leaking `segsize` (= `AMR_NSEG * AMR_MAXCMD * 8`
   bytes ≈ 8–12 KB) plus a tag/map per iteration until kmem/DMA32
   exhaustion wedges the machine during attach.
2. Same unchecked-load pattern in `amr_setup_mbox()`
   (amr_pci.c:654-655) with a worse sink: on load failure the stack
   variable `baddr` is **uninitialized**, yet it flows into
   `sc->amr_mailboxphys = baddr + offsetof(...)` (amr_pci.c:660) — the
   physical address the controller is later told to DMA completions
   to. `amr_ccb_map()` (amr_pci.c:698-699) repeats it for
   `sc->amr_ccb_busaddr`.

## Impact
Hardening / robustness (Info): the leak is certain on any system whose
DMA allocator returns a sub-0x2000 address; the load-failure branches
are practically unreachable (the memory was just allocated with the
same constraints, 1 segment), which is why consequences (unbounded
attach-time memory leak; garbage mailbox physical address programmed
into the card) are labeled speculative.

## Gating
amr hardware required — absent from the audit guest (verified), so
`inconclusive`.

## Fix
Check the `bus_dmamap_load` return value everywhere, `bus_dmamap_unload`
+ `bus_dmamem_free` the rejected block before retrying, and bound the
retry count (see `fix.diff`).