Re: [PATCH] RCU safety for vma maple tree walks

[Lorenzo Stoakes (ARM)]

Hi Andi,

Looking at https://lore.kernel.org/lkml/20260831150651.1134594-6-ak@xxxxxxxxxx/
I can see the cause of your issue - it's your own patch, exactly as we've been
telling you.

You're inserting a VMA on a uprobe_mmap() call, which is completely incorrect:

<munmap()>
  -> vma_complete()
    -> uprobe_mmap(vp->insert)
      -> install_breakpoint()
        -> ...
	  -> create_uprobe_ptwrite_page()
	    -> _install_special_mapping()

Now you're inserting a VMA, using an entirely distinct iterator, while an
existing VMA iterator is in use.

That means you can end up rebalancing the tree and _trashing the iterator_ in
the core mm code.

Your (LLM's) proposed solution to this was to keep on doing the completely
broken thing, but by inserting various RCU locks, preventing a KASAN report on
use-after-free's due to avoiding an RCU grace period expiring.

You can't reproduce this upstream, because the bug is in your (RFC) series.

So, exactly as we've been trying to tell you.

> Assisted-by: omp:gpt-5.6-luna

I'm a little grumpy about this as you've taken up a bunch of our time to assess
two sets of completely broken LLM-generated code, and you've mostly responded by
denying what the authors of this code have repeatedly told you.

You also seem to be using one of the lightest weight LLM models - it isn't a
great choice for core kernel work, especially in areas you are unfamiliar with.

In future, please audit the code and make sure you understand every part of it
as per https://docs.kernel.org/process/generated-content.html

	As with the output of any tooling, the result may be incorrect or
	inappropriate. You are expected to understand and to be able to defend
	everything you submit. If you are unable to do so, then do not submit
	the resulting changes.

Please respect our time moving forwards, thanks.

--
Cheers, Lorenzo