hugemmap24: increase the baseline of slice_boundary according to hpage size

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(-)

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
>

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>

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
>
>