From: Gregory Price <gourry@gourry.net>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, akpm@linux-foundation.org,
liam@infradead.org, david@kernel.org, vbabka@kernel.org,
jannh@google.com, wangjiexun@tinylab.org,
sashiko-bot <sashiko-bot@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] mm/madvise: reclaim isolated folios if PTE restart fails
Date: Wed, 16 Sep 2026 10:42:38 -0400 [thread overview]
Message-ID: <aqqk89oTigJ9LS2N@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <aqqjW5dpyznijYLh@gremlin>
On Wed, Sep 16, 2026 at 03:12:53PM +0100, Lorenzo Stoakes (ARM) wrote:
> >
> > Going to spend a little more time testing and tweaking before I post it.
> >
> > I've been working on a making more extensive unit tests for certain
> > parts of mm/ and this might be a good time to look at whether I can
> > introduce a piece of it.
>
> Nice, curious as to how?
>
> Have you tried the userland VMA tests btw? Not tooting my own horn so to
> speak :P but it's nice, though it comes at a bit of a cost in how the files
> have to be set up...
>
Yes, in fact I used that as a start for exploring how I might make other
components testable the same way.
"Stubs... stubs everywhere"
There's basically 4 testing mechanisms i explored:
1) selftest
2) Usermode Linux (UML)
3) Userland stuff like VMA
4) Linux Test Project (for syscall and ABI testing)
selftests are really limited and actually create a maintenance burden,
they're not real unit tests and are highly dependent on the actual
machine configuration which is super annoying.
But, lets take the page allocator as an example.
The only piece of the page allocator that "should" (cough, simplifying
here a bit) be machine specific is zone and node configurations... but
I'm not convinced that this should require a full VM to unit-test.
(other caveat: obviously some things like RCU and interrupt contexts are
hard in userland, putting that aside for now).
We should be able to stub out the reclaim calls and at least demonstrate
basic correctness for a combinatrix of commands into the page allocator.
Anyway...
I've been looking at how to use the VMA and UML test infrastructure to
stub out even more of mm/ and generate these kinds of basic contract
tests. So far I've found bugs in a few random corners, but nothing
critical or reachable as far as i can tell - so that's nice.
Have made it compilable with ASAN and Coverage
The harness itself turns into a decent fuzzer as well for basic stupid
logic conditions, which in turn allows coverage and LLM guided fuzzing
into an easier task for any random kernel dev to start engaging in.
> I always feel like I should do more with it but don't have the time
> atm. May set the LLM on it though...
>
I will keep quoting myself.
"The thing LLMs do is make the pipe dream of test-driven-development
actually feasible."
:]
~Gregory
---
some stats from my infrastructure:
How much of mm/ is testable
24 of 130 files (excluding DAMON) — 30,108 of 187,486 lines, 16.1%.
┌─────────────────────────────────────────────┬───────┬
│ Compiled │ lines │
├─────────────────────────────────────────────┼───────┼
│ page_alloc.c │ 8,050 │
├─────────────────────────────────────────────┼───────┼
│ mempolicy.c │ 3,923 │
├─────────────────────────────────────────────┼───────┼
│ vma.c │ 3,429 │
├─────────────────────────────────────────────┼───────┼
│ memblock.c │ 2,911 │
├─────────────────────────────────────────────┼───────┼
│ util.c │ 1,317 │
├─────────────────────────────────────────────┼───────┼
│ memory-tiers.c │ 1,215 │
├─────────────────────────────────────────────┼───────┼
│ cma.c, pagewalk.c, pgtable_move.c, +15 more │ 9,263 │
└─────────────────────────────────────────────┴───────┴
┬─────────────────────────────────────────────────────┬───────┐
│ Not compiled (largest) │ lines │
┼─────────────────────────────────────────────────────┼───────┤
│ slub.c │ 9,933 │
┼─────────────────────────────────────────────────────┼───────┤
│ vmscan.c │ 8,163 │
┼─────────────────────────────────────────────────────┼───────┤
│ memory.c │ 7,603 │
┼─────────────────────────────────────────────────────┼───────┤
│ hugetlb.c │ 7,320 │
┼─────────────────────────────────────────────────────┼───────┤
│ memcontrol.c │ 6,756 │
┼─────────────────────────────────────────────────────┼───────┤
│ shmem.c │ 6,019 │
┼─────────────────────────────────────────────────────┼───────┤
│ vmalloc.c, huge_memory.c, filemap.c, ksm.c, gup.c … │ │
┴─────────────────────────────────────────────────────┴───────┘
The uncompiled chunk all need real folios, which is a problem that
I haven't tackled yet.
Coverage of what is compiled
┌──────────────────┬───────────────────┐
│ File │ Line coverage │
├──────────────────┼───────────────────┤
│ page_counter.c │ 100.0% (119/119) │
├──────────────────┼───────────────────┤
│ numa_memblks.c │ 99.5% (221/222) │
├──────────────────┼───────────────────┤
│ execmem.c │ 94.4% (271/287) │
├──────────────────┼───────────────────┤
│ page_poison.c │ 86.5% (32/37) │
├──────────────────┼───────────────────┤
│ numa_emulation.c │ 82.2% (199/242) │
├──────────────────┼───────────────────┤
│ page_alloc.c │ 79.6% (1873/2353) │
├──────────────────┼───────────────────┤
│ mempool.c │ 67.0% (179/267) │
├──────────────────┼───────────────────┤
│ page_isolation.c │ 60.8% (118/194) │
├──────────────────┼───────────────────┤
│ memremap.c │ 58.5% (137/234) │
├──────────────────┼───────────────────┤
│ mempolicy.c │ 54.1% (735/1359) │
├──────────────────┼───────────────────┤
│ mmzone.c │ 52.8% (19/36) │
├──────────────────┼───────────────────┤
│ shrinker.c │ 51.6% (174/337) │
├──────────────────┼───────────────────┤
│ cma.c │ 44.6% (206/462) │
└──────────────────┴───────────────────┘
Aggregate: 4,283 / 6,149 executable lines = 69.7%.
next prev parent reply other threads:[~2026-09-16 14:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-12 11:08 Gregory Price
2026-09-15 6:32 ` Andrew Morton
2026-09-15 14:13 ` Gregory Price
2026-09-15 15:55 ` Lorenzo Stoakes (ARM)
2026-09-15 17:00 ` Gregory Price
2026-09-16 13:18 ` Lorenzo Stoakes (ARM)
2026-09-16 14:02 ` Gregory Price
2026-09-16 14:08 ` Lorenzo Stoakes (ARM)
2026-09-15 17:12 ` Gregory Price
2026-09-16 13:03 ` Lorenzo Stoakes (ARM)
2026-09-16 13:57 ` Gregory Price
2026-09-16 14:12 ` Lorenzo Stoakes (ARM)
2026-09-16 14:42 ` Gregory Price [this message]
2026-09-16 14:48 ` David Hildenbrand (Arm)
2026-09-16 14:58 ` Gregory Price
2026-09-16 14:59 ` David Hildenbrand (Arm)
2026-09-16 15:19 ` Gregory Price
2026-09-16 15:21 ` Lorenzo Stoakes (ARM)
2026-09-16 15:24 ` David Hildenbrand (Arm)
2026-09-16 15:37 ` Gregory Price
2026-09-16 15:42 ` David Hildenbrand (Arm)
2026-09-16 16:10 ` Gregory Price
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=aqqk89oTigJ9LS2N@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=kernel-team@meta.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=sashiko-bot@kernel.org \
--cc=stable@vger.kernel.org \
--cc=vbabka@kernel.org \
--cc=wangjiexun@tinylab.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
all inboxes | Powered by JetHome®