[PATCH] mm: transhuge-stress: fix potential memory leak on realloc failure

[PATCH] mm: transhuge-stress: fix potential memory leak on realloc failure

[Haofeng Li]

From: Haofeng Li <lihaofeng@kylinos.cn>

When realloc() fails in transhuge-stress test, the original code
exits immediately without freeing the previously allocated memory,
causing a memory leak. This patch introduces a temporary pointer
to hold the realloc result, ensuring proper cleanup by freeing
the original map before exiting on allocation failure.

Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn>
---
 tools/testing/selftests/mm/transhuge-stress.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/mm/transhuge-stress.c b/tools/testing/selftests/mm/transhuge-stress.c
index 68201192e37c..cbe86c5b8de0 100644
--- a/tools/testing/selftests/mm/transhuge-stress.c
+++ b/tools/testing/selftests/mm/transhuge-stress.c
@@ -30,7 +30,7 @@ int main(int argc, char **argv)
 	int i = 0;
 	char *name = NULL;
 	double s;
-	uint8_t *map;
+	uint8_t *map, *map_tmp;
 	size_t map_len;
 	int pagemap_fd;
 	int duration = 0;
@@ -107,9 +107,12 @@ int main(int argc, char **argv)
 
 				nr_succeed++;
 				if (idx >= map_len) {
-					map = realloc(map, idx + 1);
-					if (!map)
+					map_tmp = realloc(map, idx + 1);
+					if (!map_tmp) {
+						free(map);
 						ksft_exit_fail_msg("map realloc\n");
+					}
+					map = map_tmp;
 					memset(map + map_len, 0, idx + 1 - map_len);
 					map_len = idx + 1;
 				}
-- 
2.25.1

Re: [PATCH] mm: transhuge-stress: fix potential memory leak on realloc failure

[David Hildenbrand]

On 12.09.25 10:20, Haofeng Li wrote:
> From: Haofeng Li <lihaofeng@kylinos.cn>
> 
> When realloc() fails in transhuge-stress test, the original code
> exits immediately without freeing the previously allocated memory,
> causing a memory leak. 

What do you think happens when a process exits? :)

Correct! All memory ever allocated to that process gets freed, avoiding 
any memory leaks.

-- 
Cheers

David / dhildenb

Re: [PATCH] mm: transhuge-stress: fix potential memory leak on realloc failure

[Haofeng Li]

From: David Hildenbrand <david@redhat.com>
>What do you think happens when a process exits? :)

>Correct! All memory ever allocated to that process gets freed, avoiding 
>any memory leaks.

Thanks for pointing this out. You are absolutely correct that the operating system will reclaim all allocated memory when a process exits, so there is no persistent memory leak in this specific scenario.

I opted to add explicit memory freeing in the error path primarily as a practice for better long-term maintainability:

It ensures correctness if the code structure changes in the future (e.g., becomes part of a longer-running routine).

It maintains consistency with other error paths in the codebase.

It prevents false positives from static analysis tools (like valgrind).

I'm happy to adjust it if you still think it's preferable to remove the free() in this context.

Best regards,
	Haofeng Li

Re: [PATCH] mm: transhuge-stress: fix potential memory leak on realloc failure

[David Hildenbrand]

On 12.09.25 12:10, Haofeng Li wrote:
> From: David Hildenbrand <david@redhat.com>
>> What do you think happens when a process exits? :)
> 
>> Correct! All memory ever allocated to that process gets freed, avoiding
>> any memory leaks.
> 
> Thanks for pointing this out. You are absolutely correct that the operating system will reclaim all allocated memory when a process exits, so there is no persistent memory leak in this specific scenario.
> 
> I opted to add explicit memory freeing in the error path primarily as a practice for better long-term maintainability:
> 
> It ensures correctness if the code structure changes in the future (e.g., becomes part of a longer-running routine).
> 
> It maintains consistency with other error paths in the codebase.
> 
> It prevents false positives from static analysis tools (like valgrind).
> 
> I'm happy to adjust it if you still think it's preferable to remove the free() in this context.

No code changes are required. This patch adds more complexity without 
any benefit.

-- 
Cheers

David / dhildenb