patch 'eal/linux: fix memseg length in legacy mem init' has been queued to stable release 24.11.2

Kevin Traynor ktraynor at redhat.com
Thu Feb 13 10:58:15 CET 2025


Hi,

FYI, your patch has been queued to stable release 24.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 02/17/25. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Queued patches are on a temporary branch at:
https://github.com/kevintraynor/dpdk-stable

This queued commit can be viewed at:
https://github.com/kevintraynor/dpdk-stable/commit/72cae7066a8d71dba1085f61863df406781a9fec

Thanks.

Kevin

---
>From 72cae7066a8d71dba1085f61863df406781a9fec Mon Sep 17 00:00:00 2001
From: Yang Ming <ming.1.yang at nokia-sbell.com>
Date: Thu, 2 Jan 2025 16:58:38 +0800
Subject: [PATCH] eal/linux: fix memseg length in legacy mem init
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[ upstream commit b974cbbbef6e1036e7ed7d19fefb7ef8cda0e4a1 ]

Fix the issue where OS memory is mistakenly freed with rte_free
by setting the length (len) of unused memseg to 0.

When `eal_legacy_hugepage_init()` releases the VA space for
unused memseg lists(MSLs), it does not reset MSLs' length to 0.
As a result, `mlx5_mem_is_rte()` may incorrectly identify OS
memory as rte memory.
This can lead to `mlx_free()` calling `rte_free()` on OS memory,
causing an "EAL: Error: Invalid memory" log and failing to free
the OS memory.

This issue is occasional and occurs when the DPDK program’s
memory map places the heap address range between 0 and len(32G).
In such cases, malloc may return an address less than len,
causing `mlx5_mem_is_rte()` to incorrectly treat it as rte
memory.

Also, consider how the MSL with `base_va == NULL` ends up in
`mlx5_mem_is_rte()`. It comes from `rte_mem_virt2memseg_list()`
which iterates MSLs and checks that an address belongs to
[`base_va`; `base_va+len`) without checking whether
`base_va == NULL` i.e. that the MSL is inactive. So this patch
also corrects `rte_mem_virt2memseg_list()` behavior.

Fixes: 66cc45e293ed ("mem: replace memseg with memseg lists")

Signed-off-by: Yang Ming <ming.1.yang at nokia-sbell.com>
Acked-by: Dmitry Kozlyuk <dmitry.kozliuk at gmail.com>
---
 .mailmap                   | 1 +
 lib/eal/linux/eal_memory.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/.mailmap b/.mailmap
index bd4b6778ec..7d9b19d51f 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1718,4 +1718,5 @@ Yajun Wu <yajunw at nvidia.com>
 Yangchao Zhou <zhouyates at gmail.com>
 Yanglong Wu <yanglong.wu at intel.com>
+Yang Ming <ming.1.yang at nokia-sbell.com>
 Yang Zhang <zy107165 at alibaba-inc.com>
 Yanjie Xu <yanjie.xu at intel.com>
diff --git a/lib/eal/linux/eal_memory.c b/lib/eal/linux/eal_memory.c
index 45879ca743..9dda60c0e1 100644
--- a/lib/eal/linux/eal_memory.c
+++ b/lib/eal/linux/eal_memory.c
@@ -1473,4 +1473,5 @@ eal_legacy_hugepage_init(void)
 		munmap(msl->base_va, mem_sz);
 		msl->base_va = NULL;
+		msl->len = 0;
 		msl->heap = 0;
 
-- 
2.48.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2025-02-12 17:29:39.685530205 +0000
+++ 0048-eal-linux-fix-memseg-length-in-legacy-mem-init.patch	2025-02-12 17:29:34.345945900 +0000
@@ -1 +1 @@
-From b974cbbbef6e1036e7ed7d19fefb7ef8cda0e4a1 Mon Sep 17 00:00:00 2001
+From 72cae7066a8d71dba1085f61863df406781a9fec Mon Sep 17 00:00:00 2001
@@ -8,0 +9,2 @@
+[ upstream commit b974cbbbef6e1036e7ed7d19fefb7ef8cda0e4a1 ]
+
@@ -34 +35,0 @@
-Cc: stable at dpdk.org
@@ -44 +45 @@
-index 9209a716e0..19bbdbc0c8 100644
+index bd4b6778ec..7d9b19d51f 100644
@@ -47 +48 @@
-@@ -1723,4 +1723,5 @@ Yajun Wu <yajunw at nvidia.com>
+@@ -1718,4 +1718,5 @@ Yajun Wu <yajunw at nvidia.com>



More information about the stable mailing list