From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Gregory Price <gourry@gourry.net>
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 14:18:36 +0100 [thread overview]
Message-ID: <aqqTtW3vjfzH8bcY@gremlin> (raw)
In-Reply-To: <aqlzzwLOVT79Ti_7@gourry-fedora-PF4VCD3F>
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
next prev parent reply other threads:[~2026-09-16 13:18 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
2026-09-16 13:18 ` Lorenzo Stoakes (ARM) [this message]
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=aqqTtW3vjfzH8bcY@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--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=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.