From: Jan Polensky <japo@linux.ibm.com>
To: linux-mm@kvack.org
Subject: [REGRESSION] mremap() returns EFAULT instead of EPERM in LTP mseal01
Date: Thu, 17 Jul 2025 13:50:29 +0200 [thread overview]
Message-ID: <aHjjhXSAyFN_bkuY@li-276bd24c-2dcc-11b2-a85c-945b6f05615c.ibm.com> (raw)
Hello,
we've identified a regression in `mremap()` behavior introduced by:
Refrence: 680e69e07d56 ("mm/mremap: check remap conditions earlier")
Linux-Next Tag: next-20250714
The issue is detected by the LTP test `mseal01`:
++ '[' '!' -f ltp-bin/runltp ']'
++ ltp-bin/testcases/bin/mseal01
tst_test.c:1999: TINFO: LTP version: 20250530-79-g39072797fa63
tst_test.c:2002: TINFO: Tested kernel: 6.16.0-rc5-testing-00315-g680e69e07d56 #1 SMP PREEMPT Thu Jul 17 10:59:57 CEST 2025 s390x
tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
tst_kconfig.c:676: TINFO: CONFIG_PROVE_LOCKING kernel option detected which might slow the execution
tst_test.c:1820: TINFO: Overall timeout per run is 0h 02m 00s
mseal01.c:130: TINFO: Testing mprotect() availability
mseal01.c:132: TPASS: sys_mseal(mem_addr + mem_offset, mem_alignment) passed
mseal01.c:45: TPASS: mprotect(mem_addr, mem_size, PROT_NONE) : EPERM (1)
mseal01.c:130: TINFO: Testing pkey_mprotect() availability
mseal01.c:132: TPASS: sys_mseal(mem_addr + mem_offset, mem_alignment) passed
../../../../include/lapi/pkey.h:43: TCONF: syscall(385) __NR_pkey_alloc not supported on your arch
mseal01.c:130: TINFO: Testing madvise() availability
mseal01.c:132: TPASS: sys_mseal(mem_addr + mem_offset, mem_alignment) passed
mseal01.c:70: TPASS: madvise(mem_addr, mem_size, MADV_DONTNEED) : EPERM (1)
mseal01.c:130: TINFO: Testing munmap() availability from child
mseal01.c:132: TPASS: sys_mseal(mem_addr + mem_offset, mem_alignment) passed
mseal01.c:75: TPASS: munmap(mem_addr, mem_size) : EPERM (1)
mseal01.c:130: TINFO: Testing mremap() address move/resize
mseal01.c:132: TPASS: sys_mseal(mem_addr + mem_offset, mem_alignment) passed
mseal01.c:88: TFAIL: mremap(mem_addr, mem_size, new_size, MREMAP_MAYMOVE | MREMAP_FIXED, new_addr) expected EPERM: EFAULT (14)
mseal01.c:130: TINFO: Testing mmap() protection change
mseal01.c:132: TPASS: sys_mseal(mem_addr + mem_offset, mem_alignment) passed
mseal01.c:98: TPASS: mmap(mem_addr, mem_size, PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0) : EPERM (1)
Summary:
passed 10
failed 1
broken 0
skipped 1
warnings 0
Works before/without the above commit.
LTP-Version:
20250530
Compiler:
gcc (GCC) 15.1.1 20250425 (Red Hat 15.1.1-1)
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Let me know if further details or a reproducer are needed.
Best regards,
Jan
next reply other threads:[~2025-07-17 11:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 11:50 Jan Polensky [this message]
2025-07-22 11:58 ` Jan Polensky
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=aHjjhXSAyFN_bkuY@li-276bd24c-2dcc-11b2-a85c-945b6f05615c.ibm.com \
--to=japo@linux.ibm.com \
--cc=linux-mm@kvack.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