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

[wangtao <tao.wangtao@honor.com>]

> > 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 very much for your reply.

I took an initial look at the cow-context code, and a few points  
might be worth noting:

1. cow_context_walk currently assumes that the rmap walk runs  
   under RCU protection. This may need to be adjusted early,  
   since paths such as try_to_unmap_one, page_vma_mkclean_one,  
   and try_to_migrate_one may involve task switching.

2. In cow_context_walk, traverse_contexts appears to involve  
   multiple nested loops. When there are many child processes  
   across several fork layers, it may not be as simple or  
   efficient as the current anon_vma approach.

   It needs to traverse all child cow_ctx, and within each  
   cow_ctx, remaps_for_each() has two levels of iteration:  
   remaps_for_each_entry and remaps_for_each_entry_offset.

   In other words, it first iterates over cow_ctx and then  
   traverses rmap_mt inside each one. The rough complexity  
   seems to be O(#proc * log(#rmap_entries_in_cow)), which  
   may be somewhat higher than anon_vma's  
   O(#vmas_in_anon_vma). However, in most cases the number  
   of processes is not large, so the impact may be limited.

Previously, I also considered converting anon_vma's rb_tree  
to a mapletree. If one entry records a single VMA, the  
average overhead could be less than two longs per VMA.

However, unlike rb_tree, mapletree does not support storing  
multiple elements under a single key. The key would need to  
look like (vma_id/mm_id + pgoff). On 32-bit platforms, since  
64-bit mapletree keys are not supported yet, the remaining  
12 bits are not enough for vma_id/mm_id.

Because of this limitation, I later started thinking about  
ways to reduce anon_vma allocations instead.

I will try to find some time next week to analyze the  
cow-context design and code more thoroughly, and then  
write up a summary.

Thanks,
Tao

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