From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Tianyi Chen <hi@tychen.cc>
Cc: "Liam R . Howlett" <liam@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tools/testing/vma: cover hole filling through __mmap_region()
Date: Mon, 7 Sep 2026 08:53:20 +0100 [thread overview]
Message-ID: <ap5pmX-RddQ-c90O@gremlin> (raw)
In-Reply-To: <20260906144100.849288-1-hi@tychen.cc>
On Sun, Sep 06, 2026 at 10:41:00PM +0800, Tianyi Chen wrote:
> The mmap tests extend existing mappings one neighbor at a time, while
> merge tests construct merge state directly. Neither exercises filling
> a hole between compatible mappings through the mmap setup and completion
> path.
>
> Fill a gap through __mmap_region() and require both neighbors to merge
> into one VMA. Repeat with only the new mapping's execute permission set
> and require three separate VMAs. Check boundaries, permissions, page
> offsets, map_count and tree lookups across the mapped pages.
>
> The full VMA test suite passes all 28 tests with ASan and UBSan enabled.
>
> Assisted-by: LLM
Thanks for adding the tag, always much appreciated!
I may actually set my own LLM loose on these tests to expand some more. Is
a good area for such work I think.
Though it still needs massaging to get good code :)
> Signed-off-by: Tianyi Chen <hi@tychen.cc>
General idea seems reasonable to me, and never any harm in adding more
tests :)
A bunch of stuff to fix below, but with those addressed patch should be
good.
Also please rebase this on the mm-unstable branch of Andrew's tree:
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/
As there is a minor conflict with my upcoming work :)
> ---
> tools/testing/vma/tests/mmap.c | 75 ++++++++++++++++++++++++++++++++++
> 1 file changed, 75 insertions(+)
>
> diff --git a/tools/testing/vma/tests/mmap.c b/tools/testing/vma/tests/mmap.c
> index c85bc000d1c..b66ec932a75 100644
> --- a/tools/testing/vma/tests/mmap.c
> +++ b/tools/testing/vma/tests/mmap.c
> @@ -45,7 +45,82 @@ static bool test_mmap_region_basic(void)
> return true;
> }
>
> +static bool mmap_region_fill_hole(bool merge)
> +{
> + const vma_flags_t vma_flags = mk_vma_flags(VMA_READ_BIT, VMA_WRITE_BIT,
> + VMA_MAYREAD_BIT, VMA_MAYWRITE_BIT, VMA_MAYEXEC_BIT);
> + vma_flags_t hole_flags = vma_flags;
Hole is the wrong word, maybe 'middle_flags'?
> + struct mm_struct mm = {};
> + struct vm_area_struct *vma;
> + unsigned long addr;
> + int count = 0;
> + VMA_ITERATOR(vmi, &mm, 0);
> +
> + current->mm = &mm;
> + if (!merge)
> + vma_flags_set(&hole_flags, VMA_EXEC_BIT);
> +
> + /* Leave a hole between two otherwise mergeable mappings. */
> + addr = __mmap_region(NULL, 0x300000, 0x3000, vma_flags, 0x300, NULL);
> + ASSERT_EQ(addr, 0x300000);
> + addr = __mmap_region(NULL, 0x306000, 0x3000, vma_flags, 0x306, NULL);
> + ASSERT_EQ(addr, 0x306000);
> + ASSERT_EQ(mm.map_count, 2);
Everything here is reasonable but can you please add comments like other tests
like:
/* Map at 0x306000, length 0x3000. */
etc.
> + vma_iter_set(&vmi, 0x303000);
> + ASSERT_EQ(vma_iter_load(&vmi), NULL);
> + vma_iter_set(&vmi, 0x305fff);
> + ASSERT_EQ(vma_iter_load(&vmi), NULL);
Let's drop these 4 lines they're a bit useless I think.
> +
> + /* A single flag difference must prevent merging with either neighbor. */
Similar to above re: comment.
Also worth saying
> + addr = __mmap_region(NULL, 0x303000, 0x3000, hole_flags, 0x303, NULL);
> + ASSERT_EQ(addr, 0x303000);
> + ASSERT_EQ(mm.map_count, merge ? 1 : 3);
> +
> + vma_iter_set(&vmi, 0);
> + for_each_vma(vmi, vma) {
> + unsigned long start = 0x300000 + count * 0x3000;
> + unsigned long end = merge ? 0x309000 : start + 0x3000;
NIT: Can we make these const please?
> + VMA_ITERATOR(lookup, &mm, start);
> +
> + ASSERT_EQ(vma->vm_start, start);
> + ASSERT_EQ(vma->vm_end, end);
> + ASSERT_EQ(vma_start_pgoff(vma), start >> PAGE_SHIFT);
> + ASSERT_EQ(vma_start_anon_pgoff(vma), start >> PAGE_SHIFT);
Newline here maybe as basic stuff above.
> + ASSERT_TRUE(vma_test_all(vma, VMA_READ_BIT, VMA_WRITE_BIT,
> + VMA_MAYREAD_BIT, VMA_MAYWRITE_BIT,
> + VMA_MAYEXEC_BIT));
> + ASSERT_EQ(vma_test(vma, VMA_EXEC_BIT), !merge && count == 1);
Also can we separate out the !merge && count bit? So put this at the start
of the for_each_vma() block:
/* If testing the non-merge case, middle VMA will be set VMA_EXEC. */
const bool is_middle_vma = count == 1;
const expect_exec_vma = is_middle_vma && !merge;
Then here:
ASSERT_EQ(vma_test(vma, VMA_EXEC_BIT), expect_exec_vma);
Also a newline here would be nice.
> + for (addr = start; addr < end; addr += PAGE_SIZE) {
> + vma_iter_set(&lookup, addr);
> + ASSERT_EQ(vma_iter_load(&lookup), vma);
> + vma_iter_set(&lookup, addr + PAGE_SIZE - 1);
> + ASSERT_EQ(vma_iter_load(&lookup), vma);
> + }
Let's drop this entire block please I don't think it's achieving anything
useful.
> + count++;
> + }
Newline here please.
> + ASSERT_EQ(count, mm.map_count);
> + vma_iter_set(&vmi, 0x2fffff);
> + ASSERT_EQ(vma_iter_load(&vmi), NULL);
> + vma_iter_set(&vmi, 0x309000);
> + ASSERT_EQ(vma_iter_load(&vmi), NULL);
Again let's drop this block, it's not useful I don't think.
> +
> + ASSERT_EQ(cleanup_mm(&mm, &vmi), count);
> + return true;
> +}
> +
> +static bool test_mmap_region_fill_hole_merge(void)
> +{
> + return mmap_region_fill_hole(true);
> +}
> +
> +static bool test_mmap_region_fill_hole_flags_mismatch(void)
> +{
> + return mmap_region_fill_hole(false);
> +}
> +
> static void run_mmap_tests(int *num_tests, int *num_fail)
> {
> TEST(mmap_region_basic);
> + TEST(mmap_region_fill_hole_merge);
> + TEST(mmap_region_fill_hole_flags_mismatch);
> }
> --
> 2.55.0
>
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-09-07 7:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 14:41 [PATCH] tools/testing/vma: cover hole filling through __mmap_region() Tianyi Chen
2026-09-07 7:53 ` Lorenzo Stoakes (ARM) [this message]
2026-09-08 9:55 ` Tianyi Chen
2026-09-08 9:55 ` [PATCH v2] " Tianyi Chen
2026-09-08 10:21 ` Lorenzo Stoakes (ARM)
2026-09-08 11:37 ` Tianyi Chen
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=ap5pmX-RddQ-c90O@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hi@tychen.cc \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 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.