> -----Original Message-----
> From: Barry Song <baohua@kernel.org>
> Sent: Friday, May 29, 2026 7:31 AM
> To: Lorenzo Stoakes <ljs@kernel.org>
> Cc: wangtao <tao.wangtao@honor.com>; catalin.marinas@arm.com;
> will@kernel.org; tglx@kernel.org; mingo@redhat.com; bp@alien8.de;
> dave.hansen@linux.intel.com; x86@kernel.org; akpm@linux-foundation.org;
> david@kernel.org; willy@infradead.org; sj@kernel.org; kees@kernel.org;
> luizcap@redhat.com; zhangjiao2@cmss.chinamobile.com; kas@kernel.org;
> hpa@zytor.com; liam@infradead.org; vbabka@kernel.org; rppt@kernel.org;
> surenb@google.com; mhocko@suse.com; jack@suse.cz; riel@surriel.com;
> harry@kernel.org; jannh@google.com; jgg@ziepe.ca; jhubbard@nvidia.com;
> peterx@redhat.com; ziy@nvidia.com; baolin.wang@linux.alibaba.com;
> npache@redhat.com; ryan.roberts@arm.com; dev.jain@arm.com;
> lance.yang@linux.dev; xu.xin16@zte.com.cn; chengming.zhou@linux.dev;
> nao.horiguchi@gmail.com; matthew.brost@intel.com;
> joshua.hahnjy@gmail.com; rakie.kim@sk.com; byungchul@sk.com;
> gourry@gourry.net; ying.huang@linux.alibaba.com; apopple@nvidia.com;
> pfalcato@suse.de; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org; linux-
> mm@kvack.org; damon@lists.linux.dev; shakeel.butt@linux.dev;
> ryncsn@gmail.com; jparsana@google.com; dvander@google.com; zhangji
> <zhangji1@honor.com>; wangzicheng <wangzicheng@honor.com>
> Subject: Re: [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred
> anon_vma creation
> 
> On Thu, May 28, 2026 at 4:15 PM Lorenzo Stoakes <ljs@kernel.org> 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.
> 
Hi Barry,

Thank you for your guidance, it is very much appreciated.

I work with Tao at Honor. The motivation behind this work is genuine and practical.
The memory cost has increased significantly, and we have spent real effort investigating
and prototyping solutions to reduce it.

We're happy to join "constructive" discussions and learn from the community.

Thanks,
Zicheng

> >
> > 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

On Fri, May 29, 2026 at 02:20:38AM +0000, wangzicheng wrote:
> Hi Barry,
>
> Thank you for your guidance, it is very much appreciated.
>
> I work with Tao at Honor. The motivation behind this work is genuine and practical.
> The memory cost has increased significantly, and we have spent real effort investigating
> and prototyping solutions to reduce it.

Thanks, appreciate the input from your side Zicheng.

The series is unmergeable as-is, regardless of provenance.

What's unfortunate is that early discussion could have saved effort (and/or
tokens :). This is often the case with firms that develop something in-house in
isolation then present it to the community suddenly.

And as I said to Barry (+ Tao previously), the circumstances surrounding
this series are additionally very suspicious, and while we are fine with
LLM assistance where the authors fully understand it, it feels that this is
not the case here.

>
> We're happy to join "constructive" discussions and learn from the community.

So with the negativity above said, I'd really like us to move to a more
positive and constructive situation :)

One thing that is clear is that - we all want the same thing.

Reduced memory usage, reduced lock contention in the anon rmap.

So one thing that could be very useful is for you guys to help assist me
with testing of my anon rmap approach as it develops, and also provide
input, critique, and review.

I'd also love to be made aware of any testing you guys have done or input
on that, also any workloads where you have observed particularly
problematic memory usage or lock contention.

Please note that my work is currently under heavy development so the
proof-of-concept code provided is incomplete and not yet functional (it's
just there to give a sense of the shape).

I will likely provide a pre-RFC series to interested parties prior to
sending an RFC on-list.

I'd be more than happy to include you guys in that.

And as I said previously, I'm more than happy to engage in discussion
on-list or privately regarding this work :)

>
> Thanks,
> Zicheng

Cheers, Lorenzo