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@xxxxxxxxxx> 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@xxxxxxxxxx>
> Closes: https://sashiko.dev/#/patchset/20260821150912.183976-1-gourry@xxxxxxxxxx
> Cc: <stable@xxxxxxxxxxxxxxx>

#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