From: Danish Khateeb <danishkhateeb03@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Liam R. Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>,
David Hildenbrand <david@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Shuah Khan <shuah@kernel.org>,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org,
Danish Khateeb <danishkhateeb03@gmail.com>
Subject: [PATCH] selftests/mm: merge: reserve the far mremap() targets
Date: Tue, 20 Oct 2026 20:19:29 -0500 [thread overview]
Message-ID: <20261021011929.89150-1-danishkhateeb03@gmail.com> (raw)
The merge tests map their areas at fixed addresses within a 30-page
PROT_NONE carveout. Several mremap() tests move an area 1000 or 2000
pages away to separate it from the others, but those targets are outside
the carveout, and MREMAP_FIXED unmaps whatever is mapped there.
Under virtme-ng, the shared libraries are packed right above the
carveout and the dynamic linker starts about 4 MiB above it. The moves
then replace part of its text with an anonymous mapping, and the test
crashes in its next lazily bound call:
merge[6980]: segfault at 7f7ebb3c1e60 ip 00007f7ebb3c1e60 sp 00007ffd35fbaec8 error 14
Two to four of the mremap() tests then fail with "Test terminated
unexpectedly by signal 11", depending on the exact layout. On a host
where libc is mapped at a 2 MiB aligned address, the targets happen to
land above the dynamic linker and the tests pass.
Make the carveout large enough to contain the targets.
Fixes: 4e25f85b9f85 ("tools/testing/selftests: add mremap() unfaulted/faulted test cases")
Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>
---
Notes:
Tested under virtme-ng (9p root, glibc 2.44) on next-20261020 with a
KASAN/lockdep kernel, three runs of each binary:
merge before: pass:22 fail:4 skip:1 (SIGSEGV in ld-linux-x86-64.so.2)
merge after: pass:26 fail:0 skip:1
A /proc/self/maps dump at the first far move shows the target inside
the text of ld-linux-x86-64.so.2. The same tests crash under virtme-ng
with v7.2 and v7.3-rc7 kernels, so this is not caused by a kernel
change. On the host (glibc 2.44, libc mapped 2 MiB aligned) the results
are the same with and without the patch.
An LLM was used to help with this patch.
tools/testing/selftests/mm/merge.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/mm/merge.c b/tools/testing/selftests/mm/merge.c
index 7dd2933417c1..8291c208f0ae 100644
--- a/tools/testing/selftests/mm/merge.c
+++ b/tools/testing/selftests/mm/merge.c
@@ -22,9 +22,17 @@ FIXTURE(merge)
struct procmap_fd procmap;
};
+/*
+ * Some tests move a mapping 1000 or 2000 pages away with MREMAP_FIXED, which
+ * unmaps whatever is mapped at the target, so make the carveout cover those
+ * targets too. Otherwise the test can unmap its own code, such as the text of
+ * the dynamic linker.
+ */
+#define CARVEOUT_PAGES 2048
+
static char *map_carveout(unsigned int page_size)
{
- return mmap(NULL, 30 * page_size, PROT_NONE,
+ return mmap(NULL, CARVEOUT_PAGES * page_size, PROT_NONE,
MAP_ANON | MAP_PRIVATE, -1, 0);
}
@@ -73,7 +81,7 @@ FIXTURE_SETUP(merge)
FIXTURE_TEARDOWN(merge)
{
- ASSERT_EQ(munmap(self->carveout, 30 * self->page_size), 0);
+ ASSERT_EQ(munmap(self->carveout, CARVEOUT_PAGES * self->page_size), 0);
/* May fail for parent of forked process. */
close_procmap(&self->procmap);
/*
@@ -115,7 +123,7 @@ FIXTURE_SETUP(merge_with_fork)
FIXTURE_TEARDOWN(merge_with_fork)
{
- ASSERT_EQ(munmap(self->carveout, 30 * self->page_size), 0);
+ ASSERT_EQ(munmap(self->carveout, CARVEOUT_PAGES * self->page_size), 0);
ASSERT_EQ(close_procmap(&self->procmap), 0);
/* See above. */
prctl(PR_SET_MEMORY_MERGE, 0, 0, 0, 0);
base-commit: 59d7f9ec14ad4b6f38c04d254f8f2bfb991e888e
--
2.56.0
next reply other threads:[~2026-10-21 1:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 1:19 Danish Khateeb [this message]
2026-10-21 2:54 ` Gregory Price (Meta)
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=20261021011929.89150-1-danishkhateeb03@gmail.com \
--to=danishkhateeb03@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®