* [LTP] [PATCH] hugemmap24: increase the baseline of slice_boundary according to hpage size
@ 2023-04-27 3:40 Li Wang
2023-04-27 8:37 ` Jan Stancek
0 siblings, 1 reply; 4+ messages in thread
From: Li Wang @ 2023-04-27 3:40 UTC (permalink / raw)
To: ltp; +Cc: Fanhui Meng
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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [LTP] [PATCH] hugemmap24: increase the baseline of slice_boundary according to hpage size
2023-04-27 3:40 [LTP] [PATCH] hugemmap24: increase the baseline of slice_boundary according to hpage size Li Wang
@ 2023-04-27 8:37 ` Jan Stancek
2023-04-27 12:33 ` Cyril Hrubis
0 siblings, 1 reply; 4+ messages in thread
From: Jan Stancek @ 2023-04-27 8:37 UTC (permalink / raw)
To: Li Wang; +Cc: ltp, Fanhui Meng
On Thu, Apr 27, 2023 at 5:40 AM Li Wang <liwang@redhat.com> wrote:
>
> 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)
It's an improvement, but the issue of usage of MAP_FIXED remains.
No harm taking the patch, but we should likely still rewrite this test.
Acked-by: Jan Stancek <jstancek@redhat.com>
>
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LTP] [PATCH] hugemmap24: increase the baseline of slice_boundary according to hpage size
2023-04-27 8:37 ` Jan Stancek
@ 2023-04-27 12:33 ` Cyril Hrubis
2023-04-27 12:47 ` Li Wang
0 siblings, 1 reply; 4+ messages in thread
From: Cyril Hrubis @ 2023-04-27 12:33 UTC (permalink / raw)
To: Jan Stancek; +Cc: Fanhui Meng, ltp
Hi!
> It's an improvement, but the issue of usage of MAP_FIXED remains.
> No harm taking the patch, but we should likely still rewrite this test.
>
> Acked-by: Jan Stancek <jstancek@redhat.com>
I suppose that this is a band-aid that can go in before the release, but
as Jan said the test needs to be redesigned.
Acked-by: Cyril Hrubis <chrubis@suse.cz>
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LTP] [PATCH] hugemmap24: increase the baseline of slice_boundary according to hpage size
2023-04-27 12:33 ` Cyril Hrubis
@ 2023-04-27 12:47 ` Li Wang
0 siblings, 0 replies; 4+ messages in thread
From: Li Wang @ 2023-04-27 12:47 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: ltp, Fanhui Meng
Hi,
On Thu, Apr 27, 2023 at 8:36 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
> > It's an improvement, but the issue of usage of MAP_FIXED remains.
> > No harm taking the patch, but we should likely still rewrite this test.
> >
> > Acked-by: Jan Stancek <jstancek@redhat.com>
>
> I suppose that this is a band-aid that can go in before the release, but
> as Jan said the test needs to be redesigned.
>
Sure, I agree with you both. I will be thinking redesign the structure of
this test then.
Patch applied. thanks!
>
> Acked-by: Cyril Hrubis <chrubis@suse.cz>
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
>
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-04-27 12:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-27 3:40 [LTP] [PATCH] hugemmap24: increase the baseline of slice_boundary according to hpage size Li Wang
2023-04-27 8:37 ` Jan Stancek
2023-04-27 12:33 ` Cyril Hrubis
2023-04-27 12:47 ` Li Wang
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.