Re: [PATCH] mm/madvise: reclaim isolated folios if PTE restart fails

From: Gregory Price

Date: Wed Sep 16 2026 - 11:12:41 EST


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