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

[Xueming Li]

Hi,

FYI, your patch has been queued to stable release 23.11.4

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
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://git.dpdk.org/dpdk-stable/log/?h=23.11-staging

This queued commit can be viewed at:
https://git.dpdk.org/dpdk-stable/commit/?h=23.11-staging&id=a242697f142110e44ed2c17385bd138993e585e8

Thanks.

Xueming Li <xuemingl at nvidia.com>

---
>From a242697f142110e44ed2c17385bd138993e585e8 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
Cc: Xueming Li <xuemingl at nvidia.com>

[ 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 658de81358..60eac79c6b 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1630,6 +1630,7 @@ Yahui Cao <yahui.cao at intel.com>
 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>
 Yan Xia <yanx.xia at 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.34.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2025-02-18 19:39:01.893148730 +0800
+++ 0032-eal-linux-fix-memseg-length-in-legacy-mem-init.patch	2025-02-18 19:39:00.528244065 +0800
@@ -1 +1 @@
-From b974cbbbef6e1036e7ed7d19fefb7ef8cda0e4a1 Mon Sep 17 00:00:00 2001
+From a242697f142110e44ed2c17385bd138993e585e8 Mon Sep 17 00:00:00 2001
@@ -7,0 +8,3 @@
+Cc: Xueming Li <xuemingl at nvidia.com>
+
+[ upstream commit b974cbbbef6e1036e7ed7d19fefb7ef8cda0e4a1 ]
@@ -34 +36,0 @@
-Cc: stable at dpdk.org
@@ -44 +46 @@
-index 9209a716e0..19bbdbc0c8 100644
+index 658de81358..60eac79c6b 100644
@@ -47 +49 @@
-@@ -1722,6 +1722,7 @@ Yahui Cao <yahui.cao at intel.com>
+@@ -1630,6 +1630,7 @@ Yahui Cao <yahui.cao at intel.com>
@@ -56 +58 @@
-index 45879ca743..9dda60c0e1 100644
+index 9b6f08fba8..077f77d406 100644