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

[luca.boccassi@gmail.com]

Hi,

FYI, your patch has been queued to stable release 22.11.8

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/19/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/bluca/dpdk-stable

This queued commit can be viewed at:
https://github.com/bluca/dpdk-stable/commit/8d10eae3cd0ec8c0970339a8ae91eac7487f549a

Thanks.

Luca Boccassi

---
From 8d10eae3cd0ec8c0970339a8ae91eac7487f549a Mon Sep 17 00:00:00 2001
From: Yang Ming <ming.1.yang@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@nokia-sbell.com>
Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
---
 .mailmap                   | 1 +
 lib/eal/linux/eal_memory.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/.mailmap b/.mailmap
index 9b6f5f770d..fdcfe1c30a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1559,6 +1559,7 @@ Yahui Cao <yahui.cao@intel.com>
 Yajun Wu <yajunw@nvidia.com>
 Yangchao Zhou <zhouyates@gmail.com>
 Yanglong Wu <yanglong.wu@intel.com>
+Yang Ming <ming.1.yang@nokia-sbell.com>
 Yang Zhang <zy107165@alibaba-inc.com>
 Yanjie Xu <yanjie.xu@intel.com>
 Yan Xia <yanx.xia@intel.com>
diff --git a/lib/eal/linux/eal_memory.c b/lib/eal/linux/eal_memory.c
index 9b6f08fba8..077f77d406 100644
--- a/lib/eal/linux/eal_memory.c
+++ b/lib/eal/linux/eal_memory.c
@@ -1472,6 +1472,7 @@ eal_legacy_hugepage_init(void)
 		mem_sz = msl->len;
 		munmap(msl->base_va, mem_sz);
 		msl->base_va = NULL;
+		msl->len = 0;
 		msl->heap = 0;
 
 		/* destroy backing fbarray */
-- 
2.47.2

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2025-02-17 16:13:17.653512050 +0000
+++ 0022-eal-linux-fix-memseg-length-in-legacy-mem-init.patch	2025-02-17 16:13:16.806441593 +0000
@@ -1 +1 @@
-From b974cbbbef6e1036e7ed7d19fefb7ef8cda0e4a1 Mon Sep 17 00:00:00 2001
+From 8d10eae3cd0ec8c0970339a8ae91eac7487f549a Mon Sep 17 00:00:00 2001
@@ -8,0 +9,2 @@
+[ upstream commit b974cbbbef6e1036e7ed7d19fefb7ef8cda0e4a1 ]
+
@@ -34 +35,0 @@
-Cc: stable@dpdk.org
@@ -44 +45 @@
-index 9209a716e0..19bbdbc0c8 100644
+index 9b6f5f770d..fdcfe1c30a 100644
@@ -47 +48 @@
-@@ -1722,6 +1722,7 @@ Yahui Cao <yahui.cao@intel.com>
+@@ -1559,6 +1559,7 @@ Yahui Cao <yahui.cao@intel.com>
@@ -56 +57 @@
-index 45879ca743..9dda60c0e1 100644
+index 9b6f08fba8..077f77d406 100644