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

[Lorenzo Stoakes (Oracle)]

On Sat, Mar 21, 2026 at 07:12:13PM -0700, Roman Gushchin wrote:
> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:
>
> > On Fri, 20 Mar 2026 20:33:11 -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> >> A lot of patchsets are "failed to apply".  What is Sashiko trying to
> >> apply MM patches to?  It would take some smarts to apply the v2
> >> patchset when v1 is presently in mm.git?
> >
> > ?
>
> It's displayed in the Baseline section for every patchset.
>
> For mm patchsets if the base commit is not specified it's mm-new then
> mm-unstable then mm-stable then linux-next/HEAD and then linus/HEAD
> (and now I think that it should not only show HEAD, but the actual sha).
>
> I don't have yet support for "previous version is applied, let's revert
> it and try the new one" case. Something to add later.
>
> > The way things are going at present, I'm just not going to apply a
> > series which Sashiko "failed to apply".  And that's cool, I'll just
> > wait for a version which Sashiko was able to apply.  And then not
> > apply unless all Sashiko questions are resolved or convincingly refuted.
> >
> > Question please: if Sashiko finds an "issue" in v3 and then v4 comes
> > out with changelog words which justifies the questionable alteration, can
> > Sashiko parse that changelog justification and think "OK, never mind"?
>
> Yes, I'm planning to add it. Sashiko will have an access to previous
> versions of the patchset and the whole discussion thread and take it
> into the account.

Hmm this question presupposes that we should have to respond somehow to
Sashiko feedback, but with ~50% signal vs. noise (my experience so far)
that's just not sensible, and a painful addition to already overstrained
workload.

For instance
https://sashiko.dev/#/patchset/cover.1774029655.git.ljs%40kernel.org is
full of pretty useless stuff, including a silly hallucination
(VM_WARN_ON_ONCE() cannot be used as a conditional, it's defined as
(void)WARN_ON_ONCE() when CONFIG_DEBUG_VM is enabled).

I don't want to have to explain why exactly I'm ignoring certain things
each time.

Until the noise vs. signal is better, I really don't want Sashiko to block
anything or necessitate responses, which is why I'm very reticent to see it
send emails other than privately directly to the author perhaps.

>
> Thanks!

Thanks, Lorenzo