All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Ming <ming.1.yang@nokia-sbell.com>
To: dev@dpdk.org
Cc: Yang Ming <ming.1.yang@nokia-sbell.com>,
	anatoly.burakov@intel.com, stable@dpdk.org,
	Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Subject: [PATCH v2] eal: fix unused memseg length
Date: Thu,  2 Jan 2025 16:58:38 +0800	[thread overview]
Message-ID: <20250102085838.991-1-ming.1.yang@nokia-sbell.com> (raw)
In-Reply-To: <20241226081020.3479-1-ming.1.yang@nokia-sbell.com>

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")
Cc: anatoly.burakov@intel.com
Cc: stable@dpdk.org

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

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
@@ -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


  parent reply	other threads:[~2025-01-02  8:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-26  8:10 [PATCH] Fix unused memseg length for memory issue Yang Ming
2025-01-01 12:34 ` Dmitry Kozlyuk
2025-01-02  6:59   ` Yang Ming
2025-01-02  8:58 ` Yang Ming [this message]
2025-01-22  3:14   ` [PATCH v2] eal: fix unused memseg length Yang Ming
2025-02-07 14:41   ` David Marchand
  -- strict thread matches above, loose matches on Subject: below --
2025-01-02  7:26 Yang Ming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250102085838.991-1-ming.1.yang@nokia-sbell.com \
    --to=ming.1.yang@nokia-sbell.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.