Linux Test Project
 help / color / mirror / Atom feed
* [LTP] Suggested fix for the mremap03 syscall testcase
@ 2026-10-14 12:20 Martin Cermak via ltp
  2026-10-14 16:42 ` [LTP] Fix " linuxtestproject.agent
  2026-10-14 18:32 ` [LTP] Suggested fix for " Andrea Cervesato via ltp
  0 siblings, 2 replies; 3+ messages in thread
From: Martin Cermak via ltp @ 2026-10-14 12:20 UTC (permalink / raw)
  To: ltp, valgrind-developers, Mark Wielaard

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

Hello folks,

I suspect that LTP commit 88cfde5fbc14b23f673b81855127448a519679c0
introduced a regression it the mremap03 testcase.  I've originally
reported it as a Valgrind bug:

https://bugs.kde.org/show_bug.cgi?id=526974

But now I think it's an LTP bug.  Proposed fix:

$ cat 0001-Fix-the-mremap03-syscall-testcase.patch
From 3ddcfa8c303feeb8681632e458d71001fbfb825c Mon Sep 17 00:00:00 2001
From: Martin Cermak <mcermak@redhat.com>
Date: Wed, 14 Oct 2026 14:07:45 +0200
Subject: [PATCH] Fix the mremap03 syscall testcase

Commit 88cfde5fbc14b23f673b81855127448a519679c0 introduced a regression
in the setup() function of the mremap03 testcase.  The goal is to pass
a bad_addr to the mremap() syscall.

The original version of the setup() function did generate the bad_addr
using tst_get_bad_addr().  This gives a mapped address which is not
accessible (PROT_NONE).  The new version of the test does the same, but
unmaps that address right after that.  Valgrind flags that as an error.

This patch restores the original behavior of the setup() funcrion.
---
 testcases/kernel/syscalls/mremap/mremap03.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/testcases/kernel/syscalls/mremap/mremap03.c b/testcases/kernel/syscalls/mremap/mremap03.c
index 4e647cdca..6003657d4 100644
--- a/testcases/kernel/syscalls/mremap/mremap03.c
+++ b/testcases/kernel/syscalls/mremap/mremap03.c
@@ -35,7 +35,6 @@ static void setup(void)
 	newsize = 2 * memsize;

 	bad_addr = tst_get_bad_addr(NULL);
-	SAFE_MUNMAP(bad_addr, page_size);
 }

 static void run(void)
--
2.55.0

$

Thanks,
Martin

[-- Attachment #2: 0001-Fix-the-mremap03-syscall-testcase.patch --]
[-- Type: text/plain, Size: 1239 bytes --]

From 3ddcfa8c303feeb8681632e458d71001fbfb825c Mon Sep 17 00:00:00 2001
From: Martin Cermak <mcermak@redhat.com>
Date: Wed, 14 Oct 2026 14:07:45 +0200
Subject: [PATCH] Fix the mremap03 syscall testcase

Commit 88cfde5fbc14b23f673b81855127448a519679c0 introduced a regression
in the setup() function of the mremap03 testcase.  The goal is to pass
a bad_addr to the mremap() syscall.

The original version of the setup() function did generate the bad_addr
using tst_get_bad_addr().  This gives a mapped address which is not
accessible (PROT_NONE).  The new version of the test does the same, but
unmaps that address right after that.  Valgrind flags that as an error.

This patch restores the original behavior of the setup() funcrion.
---
 testcases/kernel/syscalls/mremap/mremap03.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/testcases/kernel/syscalls/mremap/mremap03.c b/testcases/kernel/syscalls/mremap/mremap03.c
index 4e647cdca..6003657d4 100644
--- a/testcases/kernel/syscalls/mremap/mremap03.c
+++ b/testcases/kernel/syscalls/mremap/mremap03.c
@@ -35,7 +35,6 @@ static void setup(void)
 	newsize = 2 * memsize;
 
 	bad_addr = tst_get_bad_addr(NULL);
-	SAFE_MUNMAP(bad_addr, page_size);
 }
 
 static void run(void)
-- 
2.55.0


[-- Attachment #3: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [LTP] Fix the mremap03 syscall testcase
  2026-10-14 12:20 [LTP] Suggested fix for the mremap03 syscall testcase Martin Cermak via ltp
@ 2026-10-14 16:42 ` linuxtestproject.agent
  2026-10-14 18:32 ` [LTP] Suggested fix for " Andrea Cervesato via ltp
  1 sibling, 0 replies; 3+ messages in thread
From: linuxtestproject.agent @ 2026-10-14 16:42 UTC (permalink / raw)
  To: Martin Cermak; +Cc: ltp

Hi Martin,

On Wed, 14 Oct 2026, Martin Cermak wrote:
> Fix the mremap03 syscall testcase

> diff --git a/testcases/kernel/syscalls/mremap/mremap03.c b/testcases/kernel/syscalls/mremap/mremap03.c
> @@ -35,7 +35,6 @@ static void setup(void)
>  	bad_addr = tst_get_bad_addr(NULL);
> -	SAFE_MUNMAP(bad_addr, page_size);

tst_get_bad_addr() returns a mapped PROT_NONE page, which mremap() can
resize; deleting this line drops the documented unmapped-old_address case.
The test still passes because old_size is 1000 pages and extends beyond
that VMA, exercising a different EFAULT check. Keep SAFE_MUNMAP() here to
preserve coverage of an unmapped old_address.

> This patch restores the original behavior of the setup() funcrion.

The commit message is missing the required Signed-off-by: trailer.
Add it at the end of the message.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [LTP] Suggested fix for the mremap03 syscall testcase
  2026-10-14 12:20 [LTP] Suggested fix for the mremap03 syscall testcase Martin Cermak via ltp
  2026-10-14 16:42 ` [LTP] Fix " linuxtestproject.agent
@ 2026-10-14 18:32 ` Andrea Cervesato via ltp
  1 sibling, 0 replies; 3+ messages in thread
From: Andrea Cervesato via ltp @ 2026-10-14 18:32 UTC (permalink / raw)
  To: Martin Cermak; +Cc: valgrind-developers, Mark Wielaard, ltp

Hi Martin,

you are right. That’s a bug we didn’t spot during the test rewrite. Thanks.

Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>

> On 14. Oct 2026, at 14:20, Martin Cermak via ltp <ltp@lists.linux.it> wrote:
> 
> Hello folks,
> 
> I suspect that LTP commit 88cfde5fbc14b23f673b81855127448a519679c0
> introduced a regression it the mremap03 testcase.  I've originally
> reported it as a Valgrind bug:
> 
> https://bugs.kde.org/show_bug.cgi?id=526974
> 
> But now I think it's an LTP bug.  Proposed fix:
> 
> $ cat 0001-Fix-the-mremap03-syscall-testcase.patch
> From 3ddcfa8c303feeb8681632e458d71001fbfb825c Mon Sep 17 00:00:00 2001
> From: Martin Cermak <mcermak@redhat.com>
> Date: Wed, 14 Oct 2026 14:07:45 +0200
> Subject: [PATCH] Fix the mremap03 syscall testcase
> 
> Commit 88cfde5fbc14b23f673b81855127448a519679c0 introduced a regression
> in the setup() function of the mremap03 testcase.  The goal is to pass
> a bad_addr to the mremap() syscall.
> 
> The original version of the setup() function did generate the bad_addr
> using tst_get_bad_addr().  This gives a mapped address which is not
> accessible (PROT_NONE).  The new version of the test does the same, but
> unmaps that address right after that.  Valgrind flags that as an error.
> 
> This patch restores the original behavior of the setup() funcrion.
> ---
> testcases/kernel/syscalls/mremap/mremap03.c | 1 -
> 1 file changed, 1 deletion(-)
> 
> diff --git a/testcases/kernel/syscalls/mremap/mremap03.c b/testcases/kernel/syscalls/mremap/mremap03.c
> index 4e647cdca..6003657d4 100644
> --- a/testcases/kernel/syscalls/mremap/mremap03.c
> +++ b/testcases/kernel/syscalls/mremap/mremap03.c
> @@ -35,7 +35,6 @@ static void setup(void)
>    newsize = 2 * memsize;
> 
>    bad_addr = tst_get_bad_addr(NULL);
> -    SAFE_MUNMAP(bad_addr, page_size);
> }
> 
> static void run(void)
> --
> 2.55.0
> 
> $
> 
> Thanks,
> Martin
> <0001-Fix-the-mremap03-syscall-testcase.patch>
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-10-14 18:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-14 12:20 [LTP] Suggested fix for the mremap03 syscall testcase Martin Cermak via ltp
2026-10-14 16:42 ` [LTP] Fix " linuxtestproject.agent
2026-10-14 18:32 ` [LTP] Suggested fix for " Andrea Cervesato via ltp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox