From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
David Hildenbrand <david@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
linux-mm@kvack.org
Subject: Re: [PATCH 2/6] selftests/mm: test a partial mremap() of hugetlb memory
Date: Mon, 2 Nov 2026 13:14:12 +0000 [thread overview]
Message-ID: <auiMju345AXIBVGa@gremlin> (raw)
In-Reply-To: <20261030-b4-mremap-pre-split-v1-2-c1829811aed0@toxicpanda.com>
On Fri, Oct 30, 2026 at 02:42:47PM +0000, Josef Bacik wrote:
> hugetlb-mremap only moves whole mappings, so it did not catch the
> reservation leak of a partial move.
>
> Map four private huge pages without touching them, move the second one,
> unmap everything, and check that the number of reserved huge pages is back
> where it was.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Looks sensible so:
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> tools/testing/selftests/mm/hugetlb-mremap.c | 52 +++++++++++++++++++++++++++--
> 1 file changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/mm/hugetlb-mremap.c b/tools/testing/selftests/mm/hugetlb-mremap.c
> index 9b724af66e93..9f9d6905cd6d 100644
> --- a/tools/testing/selftests/mm/hugetlb-mremap.c
> +++ b/tools/testing/selftests/mm/hugetlb-mremap.c
> @@ -95,6 +95,51 @@ static void register_region_with_uffd(char *addr, size_t len)
> ksft_print_msg("Registered memory at address %p with userfaultfd\n", addr);
> }
>
> +/*
> + * Move one page out of the middle of a private mapping that has not been
> + * touched, so that every page of it still holds its reservation. Once all of
> + * it is unmapped, all of the reservations have to be back in the pool.
> + */
> +static void test_partial_move(unsigned long hugepage_size)
> +{
> + const int flags = MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB;
> + const int prot = PROT_READ | PROT_WRITE;
> + const unsigned long nr = 4;
> + unsigned long resv = hugetlb_nr_resv_pages(hugepage_size);
> + unsigned long resv_after;
> + char *src, *dst, *addr;
> +
> + /* The pages of the test before this one can still be in use. */
> + if (!hugetlb_setup_default(resv + nr + 1)) {
> + ksft_test_result_skip("Partial move: not enough free huge pages\n");
> + return;
> + }
> +
> + src = mmap(NULL, nr * hugepage_size, prot, flags, -1, 0);
> + if (src == MAP_FAILED)
> + ksft_exit_fail_msg("mmap src: %s\n", strerror(errno));
> +
> + /* The destination has to be hugetlb-backed, mremap() replaces it. */
> + dst = mmap(NULL, hugepage_size, prot, flags, -1, 0);
> + if (dst == MAP_FAILED)
> + ksft_exit_fail_msg("mmap dst: %s\n", strerror(errno));
> +
> + addr = mremap(src + hugepage_size, hugepage_size, hugepage_size,
> + MREMAP_MAYMOVE | MREMAP_FIXED, dst);
> + if (addr == MAP_FAILED)
> + ksft_exit_fail_msg("partial mremap: %s\n", strerror(errno));
> +
> + munmap(addr, hugepage_size);
> + munmap(src, nr * hugepage_size);
> +
> + resv_after = hugetlb_nr_resv_pages(hugepage_size);
> + if (resv_after != resv)
> + ksft_print_msg("Reserved huge pages: %lu before, %lu after\n",
> + resv, resv_after);
> + ksft_test_result(resv_after == resv,
> + "Partial move returns all reservations\n");
> +}
> +
> int main(int argc, char *argv[])
> {
> unsigned long hugepage_size;
> @@ -102,7 +147,7 @@ int main(int argc, char *argv[])
> size_t length = 0;
>
> ksft_print_header();
> - ksft_set_plan(1);
> + ksft_set_plan(2);
>
> if (argc >= 2 && !strcmp(argv[1], "-h"))
> ksft_exit_fail_msg("Usage: %s [length_in_MB]\n", argv[0]);
> @@ -170,5 +215,8 @@ int main(int argc, char *argv[])
> close(fd);
>
> ksft_test_result(!ret, "Read same data\n");
> - ksft_exit(!ret);
> +
> + test_partial_move(hugepage_size);
> +
> + ksft_finished();
> }
>
> --
> 2.55.0
>
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-11-02 13:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 14:42 [PATCH 0/6] mm/mremap: report a failed split before moving anything Josef Bacik
2026-10-30 14:42 ` [PATCH 1/6] mm/mremap: fix hugetlb reservation leak on partial move Josef Bacik
2026-11-02 13:13 ` Lorenzo Stoakes (ARM)
2026-10-30 14:42 ` [PATCH 2/6] selftests/mm: test a partial mremap() of hugetlb memory Josef Bacik
2026-11-02 13:14 ` Lorenzo Stoakes (ARM) [this message]
2026-10-30 14:42 ` [PATCH 3/6] mm/mremap: reaccount on unmap failure only if accounted Josef Bacik
2026-11-02 13:17 ` Lorenzo Stoakes (ARM)
2026-10-30 14:42 ` [PATCH 4/6] mm/mremap: restore VM_ACCOUNT if the unmap fails Josef Bacik
2026-11-02 13:38 ` Lorenzo Stoakes (ARM)
2026-10-30 14:42 ` [PATCH 5/6] selftests/mm: test mremap() with an old size of 0 Josef Bacik
2026-11-02 13:39 ` Lorenzo Stoakes (ARM)
2026-10-30 14:42 ` [PATCH 6/6] mm/mremap: split first so a failed split is reported Josef Bacik
2026-10-31 19:27 ` Jose A. Perez de Azpillaga
2026-11-02 13:57 ` Lorenzo Stoakes (ARM)
2026-11-02 12:50 ` [PATCH 0/6] mm/mremap: report a failed split before moving anything Lorenzo Stoakes (ARM)
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=auiMju345AXIBVGa@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=josef@toxicpanda.com \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=pfalcato@suse.de \
--cc=vbabka@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox