|WARNING| mempool/cnxk: fix halo enable devarg parsing

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

# DPDK Patch Review

## ERRORS

**Error: Integer overflow/truncation in bounds check**

The code uses `atoi()` to parse a string into a `uint32_t`, then checks if the value is 0 or 1. However, `atoi()` returns `int` (typically 32-bit signed). If the input string represents a value outside the range of `int` (e.g., very large numbers or negative values in certain formats), the behavior is undefined or implementation-defined.

More critically, `atoi()` provides no error detection - it returns 0 for invalid input, making "0" and "garbage" indistinguishable.

Line in patch:
```c
val = atoi(value);
```

**Suggested fix:** Use `strtoul()` or the DPDK wrapper `rte_strtou32()` for proper error detection and unsigned parsing:

```c
static int
parse_halo_ena_handler(const char *key, const char *value, void *extra_args)
{
	RTE_SET_USED(key);
	uint32_t val;
	char *end;

	errno = 0;
	val = strtoul(value, &end, 10);
	if (errno != 0 || *end != '\0' || (val != 0 && val != 1))
		return -EINVAL;

	*(uint32_t *)extra_args = val;
	return 0;
}
```

Or using DPDK's safer wrapper:
```c
	if (rte_strtou32(value, NULL, 10, &val) < 0 || (val != 0 && val != 1))
		return -EINVAL;
```

This ensures that:
- Invalid input is properly detected (not silently converted to 0)
- The full string is consumed (no trailing garbage)
- Overflow is detected
- The value is parsed as unsigned

---

## WARNINGS

None.

---

## INFO

**Correctness note (patch fixes a real bug):**

The patch correctly identifies and fixes a type mismatch bug where:
1. The caller passes a `uint32_t*` but the old code stored through a `uint8_t*`
2. On little-endian systems, this wrote only the LSB, leaving upper bytes untouched
3. On big-endian systems, this would write to the wrong byte entirely
4. Values like 256 would truncate to 0 before the bounds check, bypassing validation

The fix to use `uint32_t` throughout is correct for these issues. The `atoi()` error handling issue identified above is a separate pre-existing problem that should be addressed for robustness.

Review-Result: ERROR