|SUCCESS| [v3,6/6] eal/memory: add page size VA limits EAL parameter
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Sat May 30 02:16:32 CEST 2026
Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164612
_AI Code Review_
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-30
I'll review this DPDK patch series focusing on correctness, coding style, API requirements, and guideline violations.
---
commit 0f4f34f49024583025a28640c770235da6ae1893
Author: Anatoly Burakov <anatoly.burakov at intel.com>
eal: reject non-numeric input in str to size
This patch adds validation to rte_str_to_size() to reject non-numeric
input and moves test coverage from malloc tests to string_autotest.
> diff --git a/lib/eal/common/eal_common_string_fns.c b/lib/eal/common/eal_common_string_fns.c
> index fa87831c3a..e0dc48bd80 100644
> --- a/lib/eal/common/eal_common_string_fns.c
> +++ b/lib/eal/common/eal_common_string_fns.c
> @@ -85,6 +85,10 @@ rte_str_to_size(const char *str)
>
> errno = 0;
> size = strtoull(str, &endptr, 0);
> + if (endptr == str) {
> + errno = EINVAL;
> + return 0;
> + }
> if (errno)
> return 0;
Does this code handle whitespace-only strings correctly? The test suite
includes " " as an invalid input case. When strtoull() is called with
" " it may skip leading whitespace and then fail to parse anything,
setting endptr to point past the whitespace but not equal to str. Can
this lead to the validation being bypassed?
---
commit 449777153a6be94602cf04bc8e3617a5ec92ef2a
Author: Anatoly Burakov <anatoly.burakov at intel.com>
eal/memory: remove per-list segment and memory limits
This patch removes multi-list logic and consolidates to single segment
list per memory type.
> diff --git a/lib/eal/common/eal_common_dynmem.c b/lib/eal/common/eal_common_dynmem.c
> index 8f51d6dd4a..c25197f2e9 100644
> --- a/lib/eal/common/eal_common_dynmem.c
> +++ b/lib/eal/common/eal_common_dynmem.c
[ ... ]
> @@ -105,8 +108,7 @@ eal_dynmem_memseg_lists_init(void)
> max_mem = (uint64_t)RTE_MAX_MEM_MB << 20;
> max_mem_per_type = RTE_MIN((uint64_t)RTE_MAX_MEM_MB_PER_TYPE << 20,
> max_mem / n_memtypes);
Is there potential for division by zero at eal_dynmem_memseg_lists_init()
if n_memtypes is zero? The check for n_memtypes == 0 appears after this
calculation in the original code.
> @@ -113,91 +103,47 @@ eal_dynmem_memseg_lists_init(void)
> - /* create all segment lists */
> - for (cur_seglist = 0; cur_seglist < n_seglists; cur_seglist++) {
> - if (msl_idx >= RTE_MAX_MEMSEG_LISTS) {
> - EAL_LOG(ERR,
> - "No more space in memseg lists, please increase RTE_MAX_MEMSEG_LISTS");
> - goto out;
> - }
> - msl = &mcfg->memsegs[msl_idx++];
> -
> - if (eal_memseg_list_init(msl, pagesz, n_segs,
> - socket_id, cur_seglist, true))
> - goto out;
> -
> - if (eal_memseg_list_alloc(msl, 0)) {
> - EAL_LOG(ERR, "Cannot allocate VA space for memseg list");
> - goto out;
> - }
> - }
> + if (eal_memseg_list_init(msl, pagesz, n_segs, socket_id, msl_idx, true))
> + goto out;
> +
> + if (eal_memseg_list_alloc(msl, 0)) {
> + EAL_LOG(ERR, "Cannot allocate VA space for memseg list");
> + goto out;
Does this code leak resources from eal_memseg_list_init() if
eal_memseg_list_alloc() fails? Should there be cleanup of previously
initialized memseg lists?
---
commit fe2f88f7645f745af7fec6565097b2078c3bcdcb
Author: Anatoly Burakov <anatoly.burakov at intel.com>
eal/memory: allocate all VA space in one go
This patch allocates all VA space in a single reservation and assigns
portions to memseg lists.
> diff --git a/lib/eal/common/eal_common_dynmem.c b/lib/eal/common/eal_common_dynmem.c
> index c25197f2e9..40cc989ed9 100644
> --- a/lib/eal/common/eal_common_dynmem.c
> +++ b/lib/eal/common/eal_common_dynmem.c
[ ... ]
> @@ -144,6 +173,15 @@ eal_dynmem_memseg_lists_init(void)
> /* we're successful */
> ret = 0;
> out:
> + if (ret != 0) {
> + if (mem_va_addr != NULL)
> + eal_mem_free(mem_va_addr, mem_va_len);
> + } else {
> + /* store the VA space data in shared config */
> + mcfg->mem_va_addr = (uintptr_t)mem_va_addr;
> + mcfg->mem_va_len = mem_va_len;
> + mcfg->mem_va_page_sz = mem_va_page_sz;
> + }
> return ret;
Does the error cleanup path at eal_dynmem_memseg_lists_init() also need
to clean up any memseg lists that were initialized via
eal_memseg_list_assign() before the failure occurred?
> diff --git a/lib/eal/linux/eal_memory.c b/lib/eal/linux/eal_memory.c
> index 691d8eb3cc..b4960ffa54 100644
> --- a/lib/eal/linux/eal_memory.c
> +++ b/lib/eal/linux/eal_memory.c
[ ... ]
> +static int __rte_unused
> +memseg_secondary_init_dynmem(void)
> +{
> + struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
> + int msl_idx = 0;
> + struct rte_memseg_list *msl;
> + void *mem_va_addr;
> + size_t mem_va_len;
> +
> + if (mcfg->mem_va_addr == 0 || mcfg->mem_va_len == 0 ||
> + mcfg->mem_va_page_sz == 0) {
> + EAL_LOG(ERR, "Missing shared dynamic memory VA range from primary process");
> + return -1;
> + }
> +
> + mem_va_addr = (void *)(uintptr_t)mcfg->mem_va_addr;
> + mem_va_len = mcfg->mem_va_len;
> +
> + if (eal_get_virtual_area(mem_va_addr, &mem_va_len,
> + mcfg->mem_va_page_sz, 0, 0) == NULL) {
> + EAL_LOG(ERR, "Cannot reserve VA space for hugepage memory");
> + return -1;
> + }
Does memseg_secondary_init_dynmem() need to clean up the VA reservation
from eal_get_virtual_area() if the subsequent rte_fbarray_attach() or
eal_memseg_list_assign() operations fail?
---
commit e5f69c56cc83cb73c443c4f992a325b9e6f1081e
Author: Anatoly Burakov <anatoly.burakov at intel.com>
eal/memory: get rid of global VA space limits
This patch removes global memory limits and lets VA usage scale with
NUMA nodes.
No specific correctness issues identified in this patch.
---
commit fd1309dd3e792b5fd97ad3d46872f083b5338554
Author: Anatoly Burakov <anatoly.burakov at intel.com>
eal/memory: store default segment limits in config
This patch moves memory limit configuration to internal config structure.
No specific correctness issues identified in this patch.
---
commit 1dc272787d685524a1b3abea4fb415a44af3ed9e
Author: Anatoly Burakov <anatoly.burakov at intel.com>
eal/memory: add page size VA limits EAL parameter
This patch adds --pagesz-mem option for per-page-size memory limits.
> diff --git a/lib/eal/common/eal_common_options.c b/lib/eal/common/eal_common_options.c
> index 67a7c6fb70..1049838d73 100644
> --- a/lib/eal/common/eal_common_options.c
> +++ b/lib/eal/common/eal_common_options.c
[ ... ]
> +static int
> +eal_parse_pagesz_mem(char *strval, struct internal_config *internal_cfg)
> +{
> + char strval_cpy[1024];
> + char *fields[3];
> + char *pagesz_str, *mem_str;
> + int arg_num;
> + int len;
> + unsigned int i;
> + uint64_t pagesz, mem_limit;
> + struct pagesz_mem_override *pmo;
> +
> + len = strnlen(strval, 1024);
> + if (len >= 1024) {
> + EAL_LOG(ERR, "--pagesz-mem parameter is too long");
> + return -1;
> + }
Does eal_parse_pagesz_mem() have a buffer overflow risk? The magic
constant 1024 is used for both the local buffer size and strnlen()
check, but if len equals 1024, the subsequent rte_strlcpy() may not
null-terminate strval_cpy properly since strnlen() returns 1024 when
the string is >= 1024 bytes.
More information about the test-report
mailing list