|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

### 1. Missing error handling for atoi() failure

**Location:** `parse_halo_ena_handler()`, line `val = atoi(value);`

```c
val = atoi(value);
if (val != 0 && val != 1)
    return -EINVAL;
```

**Issue:** `atoi()` returns 0 for invalid input, making it impossible to distinguish between a valid "0" and a parsing error. If the user provides non-numeric input like "halo_enable=foo", `atoi()` returns 0, which passes validation as a valid value.

**Fix:** Use `strtol()` or `strtoull()` with error checking:

```c
char *end;
unsigned long tmp;

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

val = (uint32_t)tmp;
```

### 2. Incorrect error validation logic

**Location:** `parse_halo_ena_handler()`, line `if (val != 0 && val != 1)`

```c
if (val != 0 && val != 1)
    return -EINVAL;
```

**Issue:** After the patch, `val` is `uint32_t`. With `atoi()`, the value 256 becomes 256, and the check `(256 != 0 && 256 != 1)` correctly evaluates to true, returning `-EINVAL`. However, the commit message states "so 256 was accepted as 0 and 257 as 1" which describes the **old** behavior with `uint8_t` truncation. The patch description is accurate but this finding is about the use of `atoi()` which still allows invalid values to slip through as 0.

This is covered by error #1 above - the real bug is that `atoi()` cannot distinguish parse failure from valid 0.

---

## WARNINGS

None.

---

## INFO

### 1. Consider using rte_strtouint32() (DPDK helper)

DPDK provides `rte_strtouint32()` (from `rte_string_fns.h`) which is specifically designed for parsing unsigned integers with bounds checking in devarg handlers. This would be more idiomatic than raw `strtoul()`:

```c
#include <rte_string_fns.h>

uint32_t val;

if (rte_strtouint32(value, NULL, 10, &val) != 0 || val > 1)
    return -EINVAL;

*(uint32_t *)extra_args = val;
```

### 2. Type narrowing fix is correct

The patch correctly addresses the type mismatch issue described in the commit message. The caller passes a `uint32_t *`, and the function now stores a full `uint32_t` value instead of only updating the first byte. The endianness and truncation issues mentioned in the commit message are accurately resolved by this change.

---

Review-Result: ERROR