|SUCCESS| [v2] mem: fix fbarray placement colliding with PCI BARs

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/172137

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-27

# DPDK Patch Review

## ERRORS

None.

## WARNINGS

None.

## INFO

### Code Quality Observations

**1. Error Path Resource Cleanup (lib/eal/common/eal_common_dynmem.c:189-193)**

The cleanup loop correctly destroys fbarrays for all memseg lists created so far:

```c
for (msl_idx = 0; msl_idx < n_msl; msl_idx++) {
    msl = &mcfg->memsegs[msl_idx];
    rte_fbarray_destroy(&msl->memseg_arr);
    *msl = (struct rte_memseg_list){0};
}
```

This is necessary because the patch moves `eal_memseg_list_init()` earlier in the function, before VA space reservation. If VA reservation fails, these initialized fbarrays must be cleaned up. The structure assignment to zero is a clean way to reset the list.

**2. Loop Counter Reuse (lib/eal/common/eal_common_dynmem.c:140, 167)**

The variable `msl_idx` is reused as a loop counter in two sequential loops (lines 140 and 167). Both loops iterate over `memtypes[cur_type]` with identical skip conditions. This is safe because:
- The loops execute sequentially, not nested
- The counter is reset to 0 before each loop
- The same iteration pattern ensures correct index pairing

While this reuse is technically correct, using separate counter variables would improve clarity.

**3. Overall Correctness**

The patch correctly addresses the VA space collision issue described in the commit message:
- Memseg lists are created first (including their fbarrays)
- VA space is then reserved in one go
- VA assignments proceed as before
- Error cleanup properly destroys any fbarrays created before failure

The logic is sound and the error handling is complete.

Review-Result: CLEAN