From: Li Wang <liwang@redhat.com>
To: ltp@lists.linux.it
Cc: Fanhui Meng <mengfanhui@kylinos.cn>
Subject: [LTP] [PATCH] hugemmap24: increase the baseline of slice_boundary according to hpage size
Date: Thu, 27 Apr 2023 11:40:39 +0800 [thread overview]
Message-ID: <20230427034039.46512-1-liwang@redhat.com> (raw)
This is to avoid error happens on system (aarch64: 512MB) with large huge page:
# ./hugemmap24
tst_hugepage.c:83: TINFO: 7 hugepage(s) reserved
tst_test.c:1560: TINFO: Timeout per run is 0h 00m 30s
hugemmap24.c:57: TINFO: can't use slice_boundary: 0x10000000: EINVAL (22)
hugemmap24.c:57: TINFO: can't use slice_boundary: 0x20000000: ENOMEM (12)
hugemmap24.c:57: TINFO: can't use slice_boundary: 0x30000000: EINVAL (22)
tst_test.c:1618: TBROK: Test killed by SIGSEGV!
# strace -f ./hugemmap24:
...
[pid 86580] mmap(0xfffffffff0000000, 2147483648, PROT_READ, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL
[pid 86580] write(2, "hugemmap24.c:57: \33[1;34mTINFO: \33"..., 85hugemmap24.c:57: TINFO: can't use slice_boundary: 0x30000000: EINVAL (22)) = 85
[pid 86580] mmap(NULL, 2147483648, PROT_READ, MAP_SHARED|MAP_FIXED, 3, 0) = 0
[pid 86580] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x404338} ---
[pid 86580] +++ killed by SIGSEGV (core dumped) +++
# cat /proc/meminfo
Hugepagesize: 524288 kB
Note:
This is basically an improved patch based on Jan's work, the only
difference is that to bypass the heap and avoid some potential
mmap collisions.
Patch get passed on RHEL-7/8/9 across many arches.
(x86_64, ppc64le, ppc64, aarch64, s390x)
Closes: https://github.com/linux-test-project/ltp/issues/1022
Discuss: https://lists.linux.it/pipermail/ltp/2023-March/033117.html
Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Jan Stancek <jstancek@redhat.com>
Cc: Tarun Sahu <tsahu@linux.ibm.com>
Cc: Fanhui Meng <mengfanhui@kylinos.cn>
---
testcases/kernel/mem/hugetlb/hugemmap/hugemmap24.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap24.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap24.c
index a465aadec..158a03010 100644
--- a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap24.c
+++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap24.c
@@ -23,7 +23,7 @@
static int fd = -1;
static unsigned long slice_boundary;
-static long hpage_size, page_size;
+static unsigned long hpage_size, page_size;
static int init_slice_boundary(int fd)
{
@@ -44,6 +44,13 @@ static int init_slice_boundary(int fd)
heap = malloc(1);
free(heap);
+ /* Avoid underflow on systems with large huge pages.
+ * The additionally plus heap address is to reduce the possibility
+ * of MAP_FIXED stomp over existing mappings.
+ */
+ while (slice_boundary + slice_size < (unsigned long)heap + 2*hpage_size)
+ slice_boundary += slice_size;
+
/* Find 2 neighbour slices with couple huge pages free
* around slice boundary.
* 16 is the maximum number of slices (low/high)
--
2.40.0
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next reply other threads:[~2023-04-27 3:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 3:40 Li Wang [this message]
2023-04-27 8:37 ` [LTP] [PATCH] hugemmap24: increase the baseline of slice_boundary according to hpage size Jan Stancek
2023-04-27 12:33 ` Cyril Hrubis
2023-04-27 12:47 ` Li Wang
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=20230427034039.46512-1-liwang@redhat.com \
--to=liwang@redhat.com \
--cc=ltp@lists.linux.it \
--cc=mengfanhui@kylinos.cn \
/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.