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

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

[Gregory Price]

MADV_PAGEOUT collects isolated folios on a local list before reclaiming
them after the PTE walk.  The reschedule path drops the PTE lock and then
restarts the mapping with pte_offset_map_lock().

A concurrent operation can remove or replace the PTE table while the lock
is dropped, causing pte_offset_map_lock() to return NULL.  Returning directly
in that case bypasses reclaim_pages(), leaving the collected folios off the
LRU with elevated references.

Route the failure through the existing cleanup path so any isolated folios
are reclaimed or put back.

Simplest userland pseudo-code reproducer:

p = mmap(PMD_SIZE, ANONYMOUS);
touch_every_page(p, PMD_SIZE);
parallel {
   while (1) madvise(p, PMD_SIZE, MADV_PAGEOUT);
   while (1) {
       madvise(p, PMD_SIZE, MADV_DONTNEED);
       touch_every_page(p, PMD_SIZE);
   }
}

Reproduced in qemu trivially with some explicit widening of the race window.

Fixes: b2f557a21bc8 ("mm/madvise: add cond_resched() in madvise_cold_or_pageout_pte_range()")
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260821150912.183976-1-gourry@gourry.net
Cc: <stable@vger.kernel.org>
Assisted-by: LLM
Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
---
 mm/madvise.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index 574aa2bb7c7e..ba5a3d77241a 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -464,7 +464,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 restart:
 	start_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
 	if (!start_pte)
-		return 0;
+		goto out;
 	flush_tlb_batched_pending(mm);
 	lazy_mmu_mode_enable();
 	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
@@ -568,6 +568,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 			folio_deactivate(folio);
 	}
 
+out:
 	if (start_pte) {
 		lazy_mmu_mode_disable();
 		pte_unmap_unlock(start_pte, ptl);
-- 
2.55.0

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

[Andrew Morton]

On Sat, 12 Sep 2026 07:08:32 -0400 Gregory Price <gourry@gourry.net> wrote:

> MADV_PAGEOUT collects isolated folios on a local list before reclaiming
> them after the PTE walk.  The reschedule path drops the PTE lock and then
> restarts the mapping with pte_offset_map_lock().
> 
> A concurrent operation can remove or replace the PTE table while the lock
> is dropped, causing pte_offset_map_lock() to return NULL.  Returning directly
> in that case bypasses reclaim_pages(), leaving the collected folios off the
> LRU with elevated references.

aw man, you got so close then left us hanging.

So what happened next?  Machine crashed?  Permanent leak?

> Route the failure through the existing cleanup path so any isolated folios
> are reclaimed or put back.
> 
> Simplest userland pseudo-code reproducer:
> 
> p = mmap(PMD_SIZE, ANONYMOUS);
> touch_every_page(p, PMD_SIZE);
> parallel {
>    while (1) madvise(p, PMD_SIZE, MADV_PAGEOUT);
>    while (1) {
>        madvise(p, PMD_SIZE, MADV_DONTNEED);
>        touch_every_page(p, PMD_SIZE);
>    }
> }
> 
> Reproduced in qemu trivially with some explicit widening of the race window.

How was the failure observed form userspace?  (repeating myself)

> 
> Fixes: b2f557a21bc8 ("mm/madvise: add cond_resched() in madvise_cold_or_pageout_pte_range()")
> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260821150912.183976-1-gourry@gourry.net
> Cc: <stable@vger.kernel.org>

#include "Documentation/process/stable-kernel-rules.rst"

(sorry, getting snarky.  I'm saying this stuff 100x/day at present and
it just isn't sticking).

> Assisted-by: LLM

Can I suggest you update LLM's prompts so it checks that the changelog
includes userspace-visible runtime effects and so that it checks that
the patch is approximately compliant with stable-kernel-rules?

If you do, please share that prompt with me and I'll put it in ~/.signature

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

[Gregory Price]

On Mon, Sep 14, 2026 at 11:32:09PM -0700, Andrew Morton wrote:
> On Sat, 12 Sep 2026 07:08:32 -0400 Gregory Price <gourry@gourry.net> wrote:
> 
> > MADV_PAGEOUT collects isolated folios on a local list before reclaiming
> > them after the PTE walk.  The reschedule path drops the PTE lock and then
> > restarts the mapping with pte_offset_map_lock().
> > 
> > A concurrent operation can remove or replace the PTE table while the lock
> > is dropped, causing pte_offset_map_lock() to return NULL.  Returning directly
> > in that case bypasses reclaim_pages(), leaving the collected folios off the
> > LRU with elevated references.
> 
> aw man, you got so close then left us hanging.
> 
> So what happened next?  Machine crashed?  Permanent leak?
> 

Permanent leak.

nr_isolated_anon increases reliably and does not decrease when the
process dies.

> > 
> > Fixes: b2f557a21bc8 ("mm/madvise: add cond_resched() in madvise_cold_or_pageout_pte_range()")
> > Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> > Closes: https://sashiko.dev/#/patchset/20260821150912.183976-1-gourry@gourry.net
> > Cc: <stable@vger.kernel.org>
> 
> #include "Documentation/process/stable-kernel-rules.rst"
> 
> (sorry, getting snarky.  I'm saying this stuff 100x/day at present and
> it just isn't sticking).
> 
> > Assisted-by: LLM
> 
> Can I suggest you update LLM's prompts so it checks that the changelog
> includes userspace-visible runtime effects and so that it checks that
> the patch is approximately compliant with stable-kernel-rules?
> 
> If you do, please share that prompt with me and I'll put it in ~/.signature
> 

I typically (re)write (or at least heavily edit) the messages to ensure I
actually understand what's going on.  I'll update my brainmeats.

I get it though, rather than permanent leak say how to observe said leak
(vmstat or etc). ack :]

~Gregory

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

[Lorenzo Stoakes (ARM)]

On Sat, Sep 12, 2026 at 07:08:32AM -0400, Gregory Price wrote:
> MADV_PAGEOUT collects isolated folios on a local list before reclaiming
> them after the PTE walk.  The reschedule path drops the PTE lock and then
> restarts the mapping with pte_offset_map_lock().

Is this reschedule path even necessary? It's pretty bloody sketchy.

I thought the modern approach (TM) was to not do cond_resched() and friends so
can we actually look at removing this?

>
> A concurrent operation can remove or replace the PTE table while the lock
> is dropped, causing pte_offset_map_lock() to return NULL.  Returning directly
> in that case bypasses reclaim_pages(), leaving the collected folios off the
> LRU with elevated references.
>
> Route the failure through the existing cleanup path so any isolated folios
> are reclaimed or put back.
>
> Simplest userland pseudo-code reproducer:
>
> p = mmap(PMD_SIZE, ANONYMOUS);
> touch_every_page(p, PMD_SIZE);
> parallel {
>    while (1) madvise(p, PMD_SIZE, MADV_PAGEOUT);
>    while (1) {
>        madvise(p, PMD_SIZE, MADV_DONTNEED);
>        touch_every_page(p, PMD_SIZE);
>    }
> }
>
> Reproduced in qemu trivially with some explicit widening of the race window.
>
> Fixes: b2f557a21bc8 ("mm/madvise: add cond_resched() in madvise_cold_or_pageout_pte_range()")
> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260821150912.183976-1-gourry@gourry.net
> Cc: <stable@vger.kernel.org>
> Assisted-by: LLM
> Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
> ---
>  mm/madvise.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 574aa2bb7c7e..ba5a3d77241a 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -464,7 +464,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,

This function is truly some of the absolute worst code I've read in
mm. Shocking.

>  restart:
>  	start_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
>  	if (!start_pte)
> -		return 0;
> +		goto out;
>  	flush_tlb_batched_pending(mm);
>  	lazy_mmu_mode_enable();
>  	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
> @@ -568,6 +568,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  			folio_deactivate(folio);
>  	}
>
> +out:

Seems odd to put this here for a condition that explicitly guarantees
!start_pte? It should be before the if (pageout) reclaim_pages(...);
surely?

I honestly wonder whether, rather than adding yet another label/goto into this
absolute bloody mess, whether we should just live with a bit of duplication and do:

	if (!start_pte) {
		if (pageout)
			reclaim_pages(&folio_list);
		return 0;
	}

I actually think that'd be clearer at this point than throwing in some more
indirection.

That's for the backport but somebody needs to rework this entire bloody
function going forwards...

>  	if (start_pte) {
>  		lazy_mmu_mode_disable();
>  		pte_unmap_unlock(start_pte, ptl);
> --
> 2.55.0
>

--
Cheers, Lorenzo

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

[Gregory Price]

On Tue, Sep 15, 2026 at 04:55:47PM +0100, Lorenzo Stoakes (ARM) wrote:
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 574aa2bb7c7e..ba5a3d77241a 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -464,7 +464,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> 
> This function is truly some of the absolute worst code I've read in
> mm. Shocking.
>

relevant meme: https://i.imgur.com/W0N40BK.png

No argument here. This function in particular is really horrendous.

I think i'm now 4 or 5 stacks deep on the "Thanks for fixing a bug, but
while reviewing your fix sashiko found yet another CVE-worthy bug".

I'm convinced (like you below) madvise needs some attention.

> >  restart:
> >  	start_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> >  	if (!start_pte)
> > -		return 0;
> > +		goto out;
> >  	flush_tlb_batched_pending(mm);
> >  	lazy_mmu_mode_enable();
> >  	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
> > @@ -568,6 +568,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> >  			folio_deactivate(folio);
> >  	}
> >
> > +out:
> 
> Seems odd to put this here for a condition that explicitly guarantees
> !start_pte? It should be before the if (pageout) reclaim_pages(...);
> surely?
> 

I wanted to prevent any future use of the label from skipping the
start_pte check.  The function is so bad I was err'ing on the side
of being a bit defensive without making it worse.

I suppose reasonable to say the goto is worse.

> I honestly wonder whether, rather than adding yet another label/goto into this
> absolute bloody mess, whether we should just live with a bit of duplication and do:
> 
> 	if (!start_pte) {
> 		if (pageout)
> 			reclaim_pages(&folio_list);
> 		return 0;
> 	}
> 
> I actually think that'd be clearer at this point than throwing in some more
> indirection.
> 

I'll spin a v2.

> That's for the backport but somebody needs to rework this entire bloody
> function going forwards...

The longer I look at madvise, the more I think it is a wart on mm/
as-written.  A userland-driven page table walker that requires all
the special-casing of Yooj Pages, zone device, swap, soft leafs, a
bunch of tlb flushing 5-tabs deep...

Scary surface.

I've been trying to think about how we might make this more reasonable,
but generalizing the different walkers across mm is pretty hard.

~Gregory

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

[Gregory Price]

On Tue, Sep 15, 2026 at 04:55:47PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Sat, Sep 12, 2026 at 07:08:32AM -0400, Gregory Price wrote:
> > MADV_PAGEOUT collects isolated folios on a local list before reclaiming
> > them after the PTE walk.  The reschedule path drops the PTE lock and then
> > restarts the mapping with pte_offset_map_lock().
> 
> Is this reschedule path even necessary? It's pretty bloody sketchy.
> 
> I thought the modern approach (TM) was to not do cond_resched() and friends so
> can we actually look at removing this?
> 

Sorry - meant to reply to this.

Honestly there's so much jammed into this function i can't give you a
straight answer. I can take a short detour to figure out if we can
rework this as a whole.

~Gregory

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

[Lorenzo Stoakes (ARM)]

On Tue, Sep 15, 2026 at 01:12:03PM -0400, Gregory Price wrote:
> On Tue, Sep 15, 2026 at 04:55:47PM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Sat, Sep 12, 2026 at 07:08:32AM -0400, Gregory Price wrote:
> > > MADV_PAGEOUT collects isolated folios on a local list before reclaiming
> > > them after the PTE walk.  The reschedule path drops the PTE lock and then
> > > restarts the mapping with pte_offset_map_lock().
> >
> > Is this reschedule path even necessary? It's pretty bloody sketchy.
> >
> > I thought the modern approach (TM) was to not do cond_resched() and friends so
> > can we actually look at removing this?
> >
>
> Sorry - meant to reply to this.
>
> Honestly there's so much jammed into this function i can't give you a
> straight answer. I can take a short detour to figure out if we can
> rework this as a whole.

s/short detour/long journey through hell/ perhaps? :P ;)

>
> ~Gregory

--
Cheers, Lorenzo

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

[Lorenzo Stoakes (ARM)]

On Tue, Sep 15, 2026 at 01:00:31PM -0400, Gregory Price wrote:
> On Tue, Sep 15, 2026 at 04:55:47PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > diff --git a/mm/madvise.c b/mm/madvise.c
> > > index 574aa2bb7c7e..ba5a3d77241a 100644
> > > --- a/mm/madvise.c
> > > +++ b/mm/madvise.c
> > > @@ -464,7 +464,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> >
> > This function is truly some of the absolute worst code I've read in
> > mm. Shocking.
> >
>
> relevant meme: https://i.imgur.com/W0N40BK.png

Content not viewable in my region :'( seems I do not have a loicense for
that!

>
> No argument here. This function in particular is really horrendous.
>
> I think i'm now 4 or 5 stacks deep on the "Thanks for fixing a bug, but
> while reviewing your fix sashiko found yet another CVE-worthy bug".

Yeah, I WISH it wouldn't do that.

I mean it's helpful to some degree and it finds real stuff.

But it's _where_ it does that and the workload++ aspect of it.

>
> I'm convinced (like you below) madvise needs some attention.
>
> > >  restart:
> > >  	start_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> > >  	if (!start_pte)
> > > -		return 0;
> > > +		goto out;
> > >  	flush_tlb_batched_pending(mm);
> > >  	lazy_mmu_mode_enable();
> > >  	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
> > > @@ -568,6 +568,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> > >  			folio_deactivate(folio);
> > >  	}
> > >
> > > +out:
> >
> > Seems odd to put this here for a condition that explicitly guarantees
> > !start_pte? It should be before the if (pageout) reclaim_pages(...);
> > surely?
> >
>
> I wanted to prevent any future use of the label from skipping the
> start_pte check.  The function is so bad I was err'ing on the side
> of being a bit defensive without making it worse.
>
> I suppose reasonable to say the goto is worse.

Yeah I know it's all a bit much of a muchness, and obviously my suggestion
_duplicates code_ which is also not wonderful.

But the control flow in the function I think is a bigger issue.

>
> > I honestly wonder whether, rather than adding yet another label/goto into this
> > absolute bloody mess, whether we should just live with a bit of duplication and do:
> >
> > 	if (!start_pte) {
> > 		if (pageout)
> > 			reclaim_pages(&folio_list);
> > 		return 0;
> > 	}
> >
> > I actually think that'd be clearer at this point than throwing in some more
> > indirection.
> >
>
> I'll spin a v2.

Thanks!

>
> > That's for the backport but somebody needs to rework this entire bloody
> > function going forwards...
>
> The longer I look at madvise, the more I think it is a wart on mm/
> as-written.  A userland-driven page table walker that requires all
> the special-casing of Yooj Pages, zone device, swap, soft leafs, a
> bunch of tlb flushing 5-tabs deep...
>
> Scary surface.
>
> I've been trying to think about how we might make this more reasonable,
> but generalizing the different walkers across mm is pretty hard.

I mean it's a vital interface, but it often feels the wrong one (it's meant
to be advice but several cases cannot actually be 'advisory'), and it's all
a bit of a mess.

I wouldn't be against a new interface (new system calls aren't a big deal)
but it'd have to be carefully thought through.

Like say, the complete diametric opposite of e.g. prctl :)

Anyway we have to keep supporting what's there indefinitely because users
and such and in any case we can certainly improve hellish code in
madvise.c.

>
> ~Gregory

--
Cheers, Lorenzo

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

[Gregory Price]

On Wed, Sep 16, 2026 at 02:03:29PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Tue, Sep 15, 2026 at 01:12:03PM -0400, Gregory Price wrote:
> > On Tue, Sep 15, 2026 at 04:55:47PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > On Sat, Sep 12, 2026 at 07:08:32AM -0400, Gregory Price wrote:
> > > > MADV_PAGEOUT collects isolated folios on a local list before reclaiming
> > > > them after the PTE walk.  The reschedule path drops the PTE lock and then
> > > > restarts the mapping with pte_offset_map_lock().
> > >
> > > Is this reschedule path even necessary? It's pretty bloody sketchy.
> > >
> > > I thought the modern approach (TM) was to not do cond_resched() and friends so
> > > can we actually look at removing this?
> > >
> >
> > Sorry - meant to reply to this.
> >
> > Honestly there's so much jammed into this function i can't give you a
> > straight answer. I can take a short detour to figure out if we can
> > rework this as a whole.
> 
> s/short detour/long journey through hell/ perhaps? :P ;)
> 

Not as much as you'd think.

I did it yesterday and left an agent to validate it overnight with
existing in-tree tests, LTP tests, and added some new tests.

The naming could use some work (cold_or_pageout -> lru_op, bleh),
but new call graph / pseudo-code:

• walk_page_range_vma()
  └── madvise_lru_op_pmd()              [PMD callback]
      │
      ├── PMD is a huge mapping
      │   └── madvise_lru_op_huge_pmd()
      │       ├── acquire PMD lock
      │       ├── madvise_lru_op_huge_pmd_locked()
      │       │   ├── process whole folio, or
      │       │   └── return locked+referenced split candidate
      │       ├── release PMD lock
      │       └── split folio / reclaim isolated folios
      │
      └── PMD points to a PTE table
          └── madvise_lru_op_ptes()
              ├── map PTE table and acquire PTL
              ├── madvise_lru_op_pte_range_locked()
              │   └── madvise_lru_op_pte_batch_locked()
              │       ├── process one folio/PTE batch, or
              │       └── return locked+referenced split candidate
              ├── leave lazy-MMU mode
              ├── unmap PTE table and release PTL
              ├── split candidate if necessary
              ├── reclaim isolated folios
              └── reschedule and restart from current address if necessary

Looks like a normal table walk now.  Significantly easier to review and
doesn't make my eyes vomit. (there's still an ifdef wart, but it's not
mid-function anymore... so that's nice).

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.

~Gregory

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

[Gregory Price]

On Wed, Sep 16, 2026 at 02:18:36PM +0100, Lorenzo Stoakes (ARM) wrote:
> >
> > relevant meme: https://i.imgur.com/W0N40BK.png
> 
> Content not viewable in my region :'( seems I do not have a loicense for
> that!
> 

google "reading other people's code meme" and find the comic with 

// this is bridge

:]

> >
> > No argument here. This function in particular is really horrendous.
> >
> > I think i'm now 4 or 5 stacks deep on the "Thanks for fixing a bug, but
> > while reviewing your fix sashiko found yet another CVE-worthy bug".
> 
> Yeah, I WISH it wouldn't do that.
> 
> I mean it's helpful to some degree and it finds real stuff.
> 
> But it's _where_ it does that and the workload++ aspect of it.
>

In some senses - yes it's annoying.

In other senses, it's saved me a lot of pain debugging my new work, and
I'm willing to do some cleanup on the way to new functionality.

Someone's gotta be the janitor I guess.

> > I suppose reasonable to say the goto is worse.
> 
> Yeah I know it's all a bit much of a muchness, and obviously my suggestion
> _duplicates code_ which is also not wonderful.
> 
> But the control flow in the function I think is a bigger issue.
>
...
> > I'll spin a v2.
> 
> Thanks!
>

Given i already started rewriting and validating the entire garbage
pile (see other response), mind if i just leave this as-is?  This gets
completely replaced anyway and i'd rather not have to go backward at
this point.

~Gregory

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

[Lorenzo Stoakes (ARM)]

On Wed, Sep 16, 2026 at 10:02:45AM -0400, Gregory Price wrote:
> On Wed, Sep 16, 2026 at 02:18:36PM +0100, Lorenzo Stoakes (ARM) wrote:
> > >
> > > relevant meme: https://i.imgur.com/W0N40BK.png
> >
> > Content not viewable in my region :'( seems I do not have a loicense for
> > that!
> >
>
> google "reading other people's code meme" and find the comic with
>
> // this is bridge
>
> :]
>
> > >
> > > No argument here. This function in particular is really horrendous.
> > >
> > > I think i'm now 4 or 5 stacks deep on the "Thanks for fixing a bug, but
> > > while reviewing your fix sashiko found yet another CVE-worthy bug".
> >
> > Yeah, I WISH it wouldn't do that.
> >
> > I mean it's helpful to some degree and it finds real stuff.
> >
> > But it's _where_ it does that and the workload++ aspect of it.
> >
>
> In some senses - yes it's annoying.
>
> In other senses, it's saved me a lot of pain debugging my new work, and
> I'm willing to do some cleanup on the way to new functionality.
>
> Someone's gotta be the janitor I guess.
>
> > > I suppose reasonable to say the goto is worse.
> >
> > Yeah I know it's all a bit much of a muchness, and obviously my suggestion
> > _duplicates code_ which is also not wonderful.
> >
> > But the control flow in the function I think is a bigger issue.
> >
> ...
> > > I'll spin a v2.
> >
> > Thanks!
> >
>
> Given i already started rewriting and validating the entire garbage
> pile (see other response), mind if i just leave this as-is?  This gets
> completely replaced anyway and i'd rather not have to go backward at
> this point.

Sure

And feel free to add:

Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

If I didn't say already

Because the code is right (or so I convinced myself) :)

>
> ~Gregory

--
Cheers, Lorenzo

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

[Lorenzo Stoakes (ARM)]

On Wed, Sep 16, 2026 at 09:57:44AM -0400, Gregory Price wrote:
> On Wed, Sep 16, 2026 at 02:03:29PM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Tue, Sep 15, 2026 at 01:12:03PM -0400, Gregory Price wrote:
> > > On Tue, Sep 15, 2026 at 04:55:47PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > > On Sat, Sep 12, 2026 at 07:08:32AM -0400, Gregory Price wrote:
> > > > > MADV_PAGEOUT collects isolated folios on a local list before reclaiming
> > > > > them after the PTE walk.  The reschedule path drops the PTE lock and then
> > > > > restarts the mapping with pte_offset_map_lock().
> > > >
> > > > Is this reschedule path even necessary? It's pretty bloody sketchy.
> > > >
> > > > I thought the modern approach (TM) was to not do cond_resched() and friends so
> > > > can we actually look at removing this?
> > > >
> > >
> > > Sorry - meant to reply to this.
> > >
> > > Honestly there's so much jammed into this function i can't give you a
> > > straight answer. I can take a short detour to figure out if we can
> > > rework this as a whole.
> >
> > s/short detour/long journey through hell/ perhaps? :P ;)
> >
>
> Not as much as you'd think.
>
> I did it yesterday and left an agent to validate it overnight with
> existing in-tree tests, LTP tests, and added some new tests.
>
> The naming could use some work (cold_or_pageout -> lru_op, bleh),
> but new call graph / pseudo-code:
>
> • walk_page_range_vma()
>   └── madvise_lru_op_pmd()              [PMD callback]
>       │
>       ├── PMD is a huge mapping
>       │   └── madvise_lru_op_huge_pmd()
>       │       ├── acquire PMD lock
>       │       ├── madvise_lru_op_huge_pmd_locked()
>       │       │   ├── process whole folio, or
>       │       │   └── return locked+referenced split candidate
>       │       ├── release PMD lock
>       │       └── split folio / reclaim isolated folios
>       │
>       └── PMD points to a PTE table
>           └── madvise_lru_op_ptes()
>               ├── map PTE table and acquire PTL
>               ├── madvise_lru_op_pte_range_locked()
>               │   └── madvise_lru_op_pte_batch_locked()
>               │       ├── process one folio/PTE batch, or
>               │       └── return locked+referenced split candidate
>               ├── leave lazy-MMU mode
>               ├── unmap PTE table and release PTL
>               ├── split candidate if necessary
>               ├── reclaim isolated folios
>               └── reschedule and restart from current address if necessary
>
> Looks like a normal table walk now.  Significantly easier to review and
> doesn't make my eyes vomit. (there's still an ifdef wart, but it's not
> mid-function anymore... so that's nice).

OK nice, I will have to see the code to comment intelligently though I
think :)

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

I always feel like I should do more with it but don't have the time
atm. May set the LLM on it though...

>
> ~Gregory

--
Cheers, Lorenzo

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

[Gregory Price]

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

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

[David Hildenbrand (Arm)]

On 9/16/26 16:42, Gregory Price wrote:
> 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.

I told Brendan exactly that (try stubbing it) and he tried ... and had to give
up at some point because it just wasn't feasible. ;)

-- 
Cheers,

David

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

[Gregory Price]

On Wed, Sep 16, 2026 at 04:48:04PM +0200, David Hildenbrand (Arm) wrote:
> On 9/16/26 16:42, Gregory Price wrote:
> > 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.
> 
> I told Brendan exactly that (try stubbing it) and he tried ... and had to give
> up at some point because it just wasn't feasible. ;)
> 

LLM go brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

I'll try to clean up my current pile and see what I can pull out for
some select components.  Something is better than literally nothing.

I'm trying to be careful about not causing a bigger maintenance burden
while also having some confidence in my own code.

~Gregory

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

[David Hildenbrand (Arm)]

On 9/16/26 16:58, Gregory Price wrote:
> On Wed, Sep 16, 2026 at 04:48:04PM +0200, David Hildenbrand (Arm) wrote:
>> On 9/16/26 16:42, Gregory Price wrote:
>>>
>>> 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.
>>
>> I told Brendan exactly that (try stubbing it) and he tried ... and had to give
>> up at some point because it just wasn't feasible. ;)
>>
> 
> LLM go brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

No schlop like that please, I don't want to hate my life

-- 
Cheers,

David

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

[Gregory Price]

On Wed, Sep 16, 2026 at 04:59:32PM +0200, David Hildenbrand (Arm) wrote:
> >>
> >> I told Brendan exactly that (try stubbing it) and he tried ... and had to give
> >> up at some point because it just wasn't feasible. ;)
> >>
> > 
> > LLM go brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> 
> No schlop like that please, I don't want to hate my life
> 

You missed this part:

"I'm trying to be careful about not causing a bigger maintenance burden"

I wouldn't do that to you :]

~Gregory

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

[Lorenzo Stoakes (ARM)]

On Wed, Sep 16, 2026 at 11:19:35AM -0400, Gregory Price wrote:
> On Wed, Sep 16, 2026 at 04:59:32PM +0200, David Hildenbrand (Arm) wrote:
> > >>
> > >> I told Brendan exactly that (try stubbing it) and he tried ... and had to give
> > >> up at some point because it just wasn't feasible. ;)
> > >>
> > >
> > > LLM go brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> >
> > No schlop like that please, I don't want to hate my life

Somebody doesn't realise it's all too late for that :P

Picture Pennywise the clown in a storm drain etc.

> >
>
> You missed this part:
>
> "I'm trying to be careful about not causing a bigger maintenance burden"

Yeah that'll be the hard part :))

>
> I wouldn't do that to you :]

Hmmm... wouldn't you? You want to don't you? ;)

>
> ~Gregory

--
Cheers, Lorenzo

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

[David Hildenbrand (Arm)]

On 9/16/26 17:19, Gregory Price wrote:
> On Wed, Sep 16, 2026 at 04:59:32PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> LLM go brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
>>
>> No schlop like that please, I don't want to hate my life
>>
> 
> You missed this part:
> 
> "I'm trying to be careful about not causing a bigger maintenance burden"
> 
> I wouldn't do that to you :]

I just wanted to make it very clear that I don't need another schlopped gigantic
patch series in my inbox that I'll mostly have to ignore because it's
un-reviewable ;)

-- 
Cheers,

David

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

[Gregory Price]

On Wed, Sep 16, 2026 at 05:24:43PM +0200, David Hildenbrand (Arm) wrote:
> On 9/16/26 17:19, Gregory Price wrote:
> > On Wed, Sep 16, 2026 at 04:59:32PM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>> LLM go brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> >>
> >> No schlop like that please, I don't want to hate my life
> >>
> > 
> > You missed this part:
> > 
> > "I'm trying to be careful about not causing a bigger maintenance burden"
> > 
> > I wouldn't do that to you :]
> 
> I just wanted to make it very clear that I don't need another schlopped gigantic
> patch series in my inbox that I'll mostly have to ignore because it's
> un-reviewable ;)
> 

I would never :]

But *motions generally at madvise* if this isn't schlop i don't know
what is lol.

~Gregory

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

[David Hildenbrand (Arm)]

On 9/16/26 17:37, Gregory Price wrote:
> On Wed, Sep 16, 2026 at 05:24:43PM +0200, David Hildenbrand (Arm) wrote:
>> On 9/16/26 17:19, Gregory Price wrote:
>>>
>>> You missed this part:
>>>
>>> "I'm trying to be careful about not causing a bigger maintenance burden"
>>>
>>> I wouldn't do that to you :]
>>
>> I just wanted to make it very clear that I don't need another schlopped gigantic
>> patch series in my inbox that I'll mostly have to ignore because it's
>> un-reviewable ;)
>>
> 
> I would never :]
> 
> But *motions generally at madvise* if this isn't schlop i don't know
> what is lol.

Just to be clear, I enjoy any cleanups in that area which are well written (and
your track record shows that you do exceptional work ;) ).

I would also enjoy a properly stubbed page allocator as well as I envisioned ...
as long as it's not something schlopped together and rushed out.

... of course you would never work-slop me/us like that! :)

-- 
Cheers,

David

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

[Gregory Price]

On Wed, Sep 16, 2026 at 05:42:43PM +0200, David Hildenbrand (Arm) wrote:
> On 9/16/26 17:37, Gregory Price wrote:
> > On Wed, Sep 16, 2026 at 05:24:43PM +0200, David Hildenbrand (Arm) wrote:
> >> On 9/16/26 17:19, Gregory Price wrote:
> >>>
> >>> You missed this part:
> >>>
> >>> "I'm trying to be careful about not causing a bigger maintenance burden"
> >>>
> >>> I wouldn't do that to you :]
> >>
> >> I just wanted to make it very clear that I don't need another schlopped gigantic
> >> patch series in my inbox that I'll mostly have to ignore because it's
> >> un-reviewable ;)
> >>
> > 
> > I would never :]
> > 
> > But *motions generally at madvise* if this isn't schlop i don't know
> > what is lol.
> 
> Just to be clear, I enjoy any cleanups in that area which are well written (and
> your track record shows that you do exceptional work ;) ).
> 
> I would also enjoy a properly stubbed page allocator as well as I envisioned ...
> as long as it's not something schlopped together and rushed out.
> 
> ... of course you would never work-slop me/us like that! :)
> 

It's fundamentally a bootstrapping problem.

Regardless of whether an LLM wrote the tests for page_alloc in its
current form - it's going to be schloppy, because the code itself was
never written to be testable in the first place.

That's the actual problem we're all dancing around.

~Gregory