All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.