Re: [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd()

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 23 Mar 2026 23:27:35 +0000 Pedro Falcato <pfalcato@suse.de> wrote:

> > also maple_tree), the amount of such unreviewed material which enters
> > mm-stable and mainline is very very low.
> 
> That is not what I said. I said "we don't require proper M: or R: reviews
> on patches before merging". Which as far as I know is still true when it
> comes to the process. If I have this wrong, then I'm not the only one.

People never define what they mean by "merged".  I define it as "added
to mm-stable".  Things that are in mm-unstable are unstable!  They're
subject to alteration or removal.

I pipeline things, a lot.  The main benefit if this is that material
gets sometimes *weeks* of additional testing which they would not have
otherwise received.  Also there are integration benefits - inter-tree
as well and intra-tree.

If something is getting close to mm-stable and doesn't appear
sufficiently reviewed then I'll send out bleats and if those don't work,
it gets deferred or dropped.

And, btw, it's really bad to remove material late in the cycle - that
means moving an untested code combination into mm-stable, which adds
risk.  For this reason I do ask that M:aintainers and R:eviewers be
attentive to material which is in mm-unstable and to tell me as early
as possible if I should defer or drop it.

It's a mistake that we've never defined the roles and responsibilities
of maintainers and reviewers.  If we were to define their
responsibilities, I'd place "take care of what's in mm.git" high on the
list.

> The fact that the end result is still high quality is a result of your work
> (diligently tracking down review states; yes, i've seen your quilt series file
> and its annotations) and every single one involved in the review process.
> This is not however codified into the process.

Yeah. mea cupla.

> (note: the fact that DAMON and maple tree both lack reviews from !authors
> just shows there is a very low bus factor at stake. we should fix this...)

Agree.  It would be a long haul for someone to effectively pick up
something like mapletree.

> > 
> > > Like, sure, sashiko can be useful, and is better than nothing. But unless
> > > sashiko is better than the maintainers, it should be kept as optional.
> > 
> > Rule #1 is, surely, "don't add bugs".  This thing finds bugs.  If its
> > hit rate is 50% then that's plenty high enough to justify people
> > spending time to go through and check its output.
> 
> I agree. But I don't think it's flawless enough to become mandatory.

Well, I looked at some numbers.  Data!

Searched for linux-mm emails which had from:akpm, message-body contains
"sashiko".

22 emails received replies from authors indicating that alterations
were needed.

2 emails received replies from authors indicating that no alterations
were needed

1 email received a reply from author in which I wasn't able to decide
either way.

A few more replies said "no alteration, but we need to change other
code".

10-15ish have yet to receive replies.


That's a really high hit rate!  How can we possibly not use this, if we
care about Rule #1?

> Sure. But I'm thinking about the human factor - I simply don't think either
> contributors or maintainers will be particularly less stressed with the
> introduction of obligatory AI reviews. Maintainers are still hardpressed
> to review (as is their function), and contributors need to go through the
> tool's output and figure out what's relevant (and _true_) or what's not.

Yeah, it's a matter of figuring this out as we go along.  It will be so
much better if/when people are able to use sashiko privately.  But
heck, people forget to run checkpatch ;)

> IF we were able to codify the MM process like in (https://docs.kernel.org/process/maintainer-netdev.html),
> with things like:
>  - NO patch is getting in without being 1) written by a maintainer or 2) getting Rb's and Acks from M's and R's

Sure.  Where "in" means mm-stable.

>   - Ideally both, but maple and DAMON need special casing for now, I guess.

We do get quite a lot of patches from sole maintainers.

>  - NO -next content is being accepted during the merge window. straight to /dev/null.

For sure.  Well.  I usually park these thing to take a look at after we're all
merged up, but it's usually all stale by then.

>  - review state for each patch is <here>

I generate that now, with the occasional "mm.git review status" emails.
I could run it daily and add it to mm.git or something, but this
doesn't seem to have generated much interest.

> I understand. Ideally, sashiko would be a tool that maintainers and
> reviewers (and submitters) could use to help find problems. I don't think
> having you check every AI review scales. But I also don't think we should be
> treating LLM output as if it were a normal review from an expert.

Sure,  But that hit rate is so high!