Re: [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred anon_vma creation

[Barry Song]

On Thu, May 28, 2026 at 4:15 PM Lorenzo Stoakes <ljs@xxxxxxxxxx> wrote:
>
> On Thu, May 28, 2026 at 07:57:31AM +0000, wangtao wrote:
> > > Subject: Re: [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred
> > > anon_vma creation
> > >
> > > OK I've had a look through more thoroughly now and:
> > >
> > > NAK and NAK any approach like this.
> > >
> > >
> > > Not only is this structurally all wrong, it does some insane stuff (pinning
> > > VMAs - no), the RCU usage is highly dubious and I suspect you've completely
> > > broken the anon rmap for things like migration, or have at least added very
> > > dubious edge cases.
> > >
> > > You've added insane complexity, and also have failed to add even
> > > perfunctory tests, which is also totally unacceptable.
> > >
> > > The implementation is wrong, and the approach is wrong - we do not want to
> > > extend or build on anon_vma. So this is unmergeable, or any approach like it.
> > >
> > > I also, unfortunately, strongly suspect AI here. The turn of phrase, and poor
> > > commit messages, you doing this out of nowhere with absolutely no rmap
> > > experience before, your total lack of communication before.
> > >
> > > Claude puts the probability of heavy AI usage at 85-90%, and I'm pretty
> > > convinced. Either way it's utterly unmergeable but that you (likely) used AI to
> > > generate this much work for us makes me actually pretty annoyed.
> > >
> > > As a result, I would strongly suggest you no longer submit patches for the
> > > reverse mapping part of mm, as there is now a real lack of trust.
> > >
> > > If you wish to rebuild that, I suggest you _discuss_ concepts and ideas, e.g.
> > > send stuff on-list with a [DISCUSSION] tag, and engage with the community,
> > > and go from there.
> > >
> > > It's also important to synchronise - I'm working on an anon rmap replacement
> > > that I'm more than happy to discuss with you or anybody else which should
> > > achieve the same numbers in an architecturally sound way.
> > >
> > > You going off and, in a vacuum, generating a bunch of code with an
> > > unacceptable approach is not a civil way of engaging nor is it a good use of
> > > your time, or maintainer time looking at it.
> > >
> > > Thanks, Lorenzo
> >
> > Your email is very unfriendly. I hope you can point out the specific
> > problems so we can discuss how to solve them.

Hi Tao,

Lorenzo had a discussion about rmap in Zagreb here:
https://lore.kernel.org/linux-mm/aec533b2-37a7-4f44-a279-c4aa604206ac@lucifer.local/

He also shared the PoC code here:
https://git.kernel.org/pub/scm/linux/kernel/git/ljs/linux.git/log/?h=project/cow-context

and the slides were shared as well. In case you can't find
them on linux-mm (I actually couldn't find them myself), I am
attaching them again here -
"scalable-cow-lsf-longer-version.pdf"

After coming back from Zagreb, I kept trying to find one or
two full days to read Lorenzo's code and slides carefully and
write a blog about them. Unfortunately, I have been completely
busy with other work. Sigh... we always seem to have too many
non-upstream tasks.

If possible, I'd really appreciate it if you could take a
deep dive into it and write a detailed blog post. I'd be
very eager to read it and better understand the overall design.
Otherwise, I'll try to find some time next week or later to
go through it myself.

>
> I already did, you've not responded to any of them, and I'm simply not
> spending any more time on this.
>
> The series is totally unmergeable, please do not make further rmap
> submissions.
>
> >
> > I am not good at English and need to use AI to translate commit
> > messages and comments. This reply email is also translated with AI.
> > However, the code is written by me. I do not know which AI you are
> > referring to, but the AI tools I use currently cannot effectively
> > write kernel code.
> >
>
> We're fine with using AI for language, or in general as long as there's a
> clear understanding of what's being submitted.
>
> However I'm very unconvinced that this series wasn't generated.
>
> You have 2 patches in the kernel for the entirety of 2026. One in bluetooth
> and one in the scheduler.
>
> Prior to that you have patches from 2018 in device tree drivers.
>
> You have exactly 0 contributions to mm.
>
> Out of nowhere this year you have a big series for DMA, this series for
> anon_vma, having done no work or any contributions to rmap, let alone one
> of the trickiest and most complicated areas of mm.
>
> You have a total of 39 mails on the linux-mm mailing list.
>
> Suddenly doing a giant bit of work like this using code that looks entirely
> like it's AI-generated, and which after assessment by AI gives an 85-90%
> probability of AI generation is really suspicious.
>
> Now, if I'm mistaken, and you have a different name/email/identity I missed
> with many mm contributes - I will eat my words here (the series is still
> unmergeable either way though).
>
> So sorry, there's simply no trust and as a maintainer of rmap again I must
> strongly suggest that you no longer submit patches for this part of the
> kernel.
>
> If you wish to build trust up again, begin with discussions, and maybe try
> some smaller patches in mm to demonstrate that you're genuinely acting in
> good faith?

Hi Lorenzo,

I truly believe Tao is acting with good intentions, although
the way this is being done is quite messy.

Memory costs are increasing significantly these days, and as I
understand the patchset, he is trying to save memory.

However, I don't think this is being done at the right time
or in the right way. This may also be due to cultural
differences, language barriers, information gaps, and a lack
of familiarity with the mm community.
As a non-native speaker, I can see how difficult this can
sometimes be.

I would really ask you to give Tao more chances to build
trust step by step.

Best Regards
Barry

Attachment: scalable-cow-lsf-longer-version.pdf
Description: Adobe PDF document