|WARNING| mem: fix fbarray placement colliding with PCI BARs

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/171875

_AI Code Review_

warning: review has no Review-Result line, severity inferred from prose (response may be truncated)
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-23

# DPDK Patch Review

## ERRORS

**Resource leak on error path - memseg list fbarrays not destroyed**

Lines 152-157 create memseg lists with `eal_memseg_list_init()`, which initializes the `rte_fbarray` for each list. If a later step fails (line 159: `eal_get_virtual_area()` returns NULL, or line 175: `eal_memseg_list_assign()` fails), the error path at lines 188-196 now correctly destroys these fbarrays. However, if the failure occurs at line 163 ("Cannot reserve VA space"), the code jumps to `out:` but the fbarrays created so far remain initialized - only `mem_va_addr == NULL` at that point, so `eal_mem_free()` is not called, but the fbarrays still exist.

Wait - reviewing the error path more carefully: lines 189-193 destroy all created memseg lists (0 to `n_msl-1`). Line 157 sets `n_msl = msl_idx` after each successful creation. So if `eal_get_virtual_area()` fails at line 159, `n_msl` reflects the number of successfully created lists, and the cleanup loop will destroy them all.

This is actually correct. The error path handles it properly.

**Deleted - correctness verified on re-read.**

## WARNINGS

**Missing bounds check before accessing mcfg->memsegs array**

Lines 150 and 172 access `mcfg->memsegs[msl_idx]` without verifying that `msl_idx < RTE_MAX_MEMSEG_LISTS`. While `n_memtypes` is capped at `RTE_MAX_MEMSEG_LISTS` at line 71 (visible in diff context), and the loop iterates over `cur_type < n_memtypes`, and only increments `msl_idx` when `type->n_segs != 0`, there is no explicit verification that the sum of non-zero segments across all types stays within `RTE_MAX_MEMSEG_LISTS`. If the memtypes array is constructed incorrectly elsewhere, this could cause an out-of-bounds access.

However, examining the diff context: line 71 shows `n_memtypes = RTE_MIN(n_memtypes, RTE_DIM(memtypes));` where `memtypes` is `RTE_MAX_MEMSEG_LISTS` elements. The loop at lines 140-157 and 166-182 iterates `cur_type < n_memtypes`, which is <= `RTE_MAX_MEMSEG_LISTS`. Each iteration increments `msl_idx` at most once (line 156), so `msl_idx` cannot exceed `n_memtypes`, which cannot exceed `RTE_MAX_MEMSEG_LISTS`.

This is safe. **Deleted - no issue.**

**Error path cleanup order mismatch**

The error path at lines 188-196 destroys the memseg list fbarrays (lines 189-193) before freeing the VA space (lines 194-195). However, at the point where `eal_memseg_list_assign()` fails (line 175), the VA space has been reserved (line 159) and some segment lists may have been assigned VA ranges within it (line 174). The fbarrays themselves do not map anything into the VA space - `eal_memseg_list_init()` creates the array tracking structure, and `eal_memseg_list_assign()` sets the base address. The VA space reservation is a single region (`mem_va_addr`, `mem_va_len`) that covers all segment lists.

Destroying the fbarrays before freeing the VA space is correct: the fbarrays are independent metadata structures, and the VA space is a single allocation that should be freed last.

**Deleted - order is correct.**

## INFO

**Release notes not updated**

This fix corrects an intermittent crash in secondary processes introduced by commit 3368bc8600e8. As it affects a production deployment scenario (secondary processes like `dpdk-proc-info`) and has a `Cc: stable at dpdk.org` tag, the fix should be documented in the release notes under a "Fixed Issues" or "Bug Fixes" section for the affected library (EAL memory management).

Note: This is a backport candidate (`stable at dpdk.org`), so release notes are expected.

---

All correctness checks passed on re-review. The patch correctly solves the problem described: by creating memseg lists (and their fbarrays) before reserving the VA space, nothing occupies the address immediately following the VA space, allowing PCI BARs to be mapped there as intended. The error path properly cleans up all resources allocated before the failure point.

Review-Result: INFO