[LTP] [RFC PATCH 2/2] hugemmap33: Test to detect bug with migrating gigantic pages
Cyril Hrubis
chrubis@suse.cz
Thu Sep 7 13:30:18 CEST 2023
On Wed, May 24, 2023 at 05:39:30PM +0800, Li Wang wrote:
> Signed-off-by: Li Wang <liwang@redhat.com>
> ---
> runtest/hugetlb | 1 +
> testcases/kernel/mem/.gitignore | 1 +
> .../kernel/mem/hugetlb/hugemmap/hugemmap33.c | 143 ++++++++++++++++++
> 3 files changed, 145 insertions(+)
> create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap33.c
>
> diff --git a/runtest/hugetlb b/runtest/hugetlb
> index 299c07ac9..3576e063d 100644
> --- a/runtest/hugetlb
> +++ b/runtest/hugetlb
> @@ -35,6 +35,7 @@ hugemmap29 hugemmap29
> hugemmap30 hugemmap30
> hugemmap31 hugemmap31
> hugemmap32 hugemmap32
> +hugemmap32 hugemmap33
> hugemmap05_1 hugemmap05 -m
> hugemmap05_2 hugemmap05 -s
> hugemmap05_3 hugemmap05 -s -m
> diff --git a/testcases/kernel/mem/.gitignore b/testcases/kernel/mem/.gitignore
> index 7258489ed..d130d4dcd 100644
> --- a/testcases/kernel/mem/.gitignore
> +++ b/testcases/kernel/mem/.gitignore
> @@ -34,6 +34,7 @@
> /hugetlb/hugemmap/hugemmap30
> /hugetlb/hugemmap/hugemmap31
> /hugetlb/hugemmap/hugemmap32
> +/hugetlb/hugemmap/hugemmap33
> /hugetlb/hugeshmat/hugeshmat01
> /hugetlb/hugeshmat/hugeshmat02
> /hugetlb/hugeshmat/hugeshmat03
> diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap33.c b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap33.c
> new file mode 100644
> index 000000000..12a470193
> --- /dev/null
> +++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap33.c
> @@ -0,0 +1,143 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) Linux Test Project, 2023
> + * Copyright (C) 2023, Red Hat, Inc.
> + *
> + * Author: David Hildenbrand <david@redhat.com>
> + * Port-to-LTP: Li Wang <liwang@redhat.com>
> + */
> +
> +/*\
> + * [Description]
> + *
> + * Migration code will first unmap the old page and replace the present PTE
> + * by a migration entry. Then migrate the page. Once that succeeded (and there
> + * are no unexpected page references), we replace the migration entries by
> + * proper present PTEs pointing at the new page.
> + *
> + * For ordinary pages we handle PTEs. For 2 MiB hugetlb/THP, it's PMDs.
> + * For 1 GiB hugetlb, it's PUDs.
> + *
> + * So without below commit, GUP-fast code was simply not aware that we could
> + * have migration entries stored in PUDs. Migration + GUP-fast code should be
> + * able to handle any such races.
> + *
> + * For example, GUP-fast will re-verify the PUD after pinning to make sure it
> + * didn't change. If it did change, it backs off.
> + *
> + * Migration code should detect the additional page references and back off
> + * as well.
> + *
> + * commit 15494520b776aa2eadc3e2fefae524764cab9cea
> + * Author: Qiujun Huang <hqjagain@gmail.com>
> + * Date: Thu Jan 30 22:12:10 2020 -0800
> + *
> + * mm: fix gup_pud_range
> + *
> + */
> +
> +#define _GNU_SOURCE
> +#include <stdio.h>
> +#include <pthread.h>
> +#include <unistd.h>
> +#include <stdbool.h>
> +#include <sys/mman.h>
> +#include <sys/syscall.h>
> +#include <sys/ioctl.h>
> +#include <linux/mempolicy.h>
> +#include <linux/mman.h>
> +
> +#include "lapi/syscalls.h"
> +#include "numa_helper.h"
> +#include "hugetlb.h"
> +#if HAVE_NUMA_H
> +#include <numa.h>
> +#endif
This is a bit strange, do we actually use anything from numa.h?
Because:
- if we do it should be ifdefed as well, otherwise the test will not
build without libnuma-devel
- if we do not, why do we include that header in the first place
> +static char *mem;
> +static size_t pagesize;
> +static size_t hugetlbsize;
> +static volatile int looping = 1;
> +
> +static void *migration_thread_fn(void *arg LTP_ATTRIBUTE_UNUSED)
> +{
> + while (looping) {
> + TST_EXP_PASS_SILENT(syscall(__NR_mbind, mem, hugetlbsize,
> + MPOL_LOCAL, NULL, 0x7fful, MPOL_MF_MOVE));
> + }
> +
> + return NULL;
> +}
> +
> +static void run_test(void)
> +{
> + ssize_t transferred;
> + struct iovec iov;
> + int fds[2];
> +
> + pthread_t migration_thread;
> +
> + if (!is_numa(NULL, NH_MEMS, 1))
> + tst_brk(TCONF, "requires NUMA with at least 1 node");
I guess that everything as at least 1 numa node, unless CONFIG_NUMA is
off, so I wonder if we just need needs_kconfig CONFIG_NUMA=y instead.
> + pagesize = getpagesize();
> + hugetlbsize = 1 * 1024 * 1024 * 1024u;
> +
> + mem = mmap(NULL, hugetlbsize, PROT_READ|PROT_WRITE,
> + MAP_PRIVATE|MAP_ANON|MAP_HUGETLB|MAP_HUGE_1GB,
> + -1, 0);
> + if (mem == MAP_FAILED)
> + tst_brk(TBROK | TERRNO, "mmap() failed");
> +
> + memset(mem, 1, hugetlbsize);
> +
> + /* Keep migrating the page around ... */
> + TEST(pthread_create(&migration_thread, NULL, migration_thread_fn, NULL));
> + if (TST_RET)
> + tst_brk(TBROK | TRERRNO, "pthread_create failed");
We do have SAFE_PTHREAD_CREATE()
> + while (looping) {
> + if (pipe(fds) < 0)
> + tst_brk(TBROK | TERRNO, "pipe() failed");
SAFE_PIPE()
> + iov.iov_base = mem;
> + iov.iov_len = pagesize;
> + transferred = vmsplice(fds[1], &iov, 1, 0);
> + if (transferred <= 0)
> + tst_brk(TBROK | TERRNO, "vmsplice() failed");
> +
> + close(fds[0]);
> + close(fds[1]);
SAFE_CLOSE() ?
> + if (!tst_remaining_runtime()) {
> + tst_res(TINFO, "Runtime exhausted, exiting");
> + looping = 0;
> + }
> + }
> +
> + TEST(pthread_join(migration_thread, NULL));
> + if (TST_RET)
> + tst_brk(TBROK | TRERRNO, "pthread_join failed");
SAFE_PTHREAD_...()
> + if (tst_taint_check())
> + tst_res(TFAIL, "Test resulted in kernel tainted");
> + else
> + tst_res(TPASS, "Test completed successfully");
tst_test.taint_check ?
> +}
> +
> +static struct tst_test test = {
> + .needs_root = 1,
> + .test_all = run_test,
> + .max_runtime = 60,
> + .hugepages = {2, TST_NEEDS, 1048576},
^
So this is 1GB hugepage?
I wonder if it would be bettter to
define constants for these, or at
least write it as 1024 * 1024
> + .taint_check = TST_TAINT_W | TST_TAINT_D,
> + .tags = (struct tst_tag[]) {
> + {"linux-git", "15494520b776"},
> + {}
> + },
> + .supported_archs = (const char *const []) {
> + "x86",
> + "x86_64",
> + NULL
I do not see anything x86 specific in the test code, or did I miss
something?
I guess that we can leave the test enabled for all architectures as long
as we check for the existente of the hugepages of the requested size in
the library.
> + },
> +};
> --
> 2.40.0
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
--
Cyril Hrubis
chrubis@suse.cz
More information about the ltp
mailing list