All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 15 Sep 2026 13:00:31 -0400	[thread overview]
Message-ID: <aqlzzwLOVT79Ti_7@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <aqloB0zm3RjJ47m1@gremlin>

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


  reply	other threads:[~2026-09-15 17:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-12 11:08 [PATCH] mm/madvise: reclaim isolated folios if PTE restart fails 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 [this message]
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
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=aqlzzwLOVT79Ti_7@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 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.