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

[Roman Gushchin <roman.gushchin@linux.dev>]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Thu, 19 Mar 2026 13:00:06 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
>
>> The zap_huge_pmd() function is overly complicated, clean it up and also add
>> an assert in the case that we encounter a buggy PMD entry that doesn't
>> match expectations.
>> 
>> This is motivated by a bug discovered [0] where the PMD entry was none of:
>> 
>> * A non-DAX, PFN or mixed map.
>> * The huge zero folio
>> * A present PMD entry
>> * A softleaf entry
>> 
>> In zap_huge_pmd(), but due to the bug we manged to reach this code.
>> 
>> It is useful to explicitly call this out rather than have an arbitrary NULL
>> pointer dereference happen, which also improves understanding of what's
>> going on.
>> 
>> [0]:https://lore.kernel.org/all/6b3d7ad7-49e1-407a-903d-3103704160d8@lucifer.local/
>
> AI review has questions, which I assume you've seen
> 	https://sashiko.dev/#/patchset/cover.1773924928.git.ljs%40kernel.org
>
>
>
> This isn't going well from a workflow POV.  I merge stuff (this was v2)
> then half a day later a bunch of potential issues are identified.
>
> If these reviews are useful (they seem to be, enough) then I guess I'll
> need to further increase the lag between seeing-it and merging-it.  But
> if there's a 2-day lag before I get onto a series and I'm the first to
> look at Sashiko then that won't help.
>
> So it needs to be something like
>
> 	- series is posted
> 	- 24 hours pass
> 	- submitter takes a look at the AI review, maybe prepares a new
> 	  series.
> 	- 24 hours pass
> 	- rinse, repeat
> 	- it gets merged, hopefully with some Reviewed-by"s.
>
> Not unreasonable, but it requires that submitter be made aware of
> Sashiko's comments.  At present that's via me being tiresome.
>
>
> Anyway, early days.  I'm thinking that an emailed reply-to-all from
> Sashiko will help.  Much hinges on how useful submitters find these
> questions to be - something which I'm paying close attention to...

For bpf Alexei suggested to always send the review to the author and
cc the bpf mailing list, but ignore maintainers and other mailing lists
like lkml to minimize the traffic. It sounds like a good trade off to me.

If there are concerns about polluting the mm mailing list,  maybe
something like a new list like "mm-new" / "mm-early" might work?
Idk what's the best thing here to do, just throwing some ideas.

Likely next week I'll be able to send reviews over the email
and I can send them to whoever we think it's appropriate.

Thanks!