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

[Lorenzo Stoakes (ARM)]

On Mon, Aug 31, 2026 at 12:35:30PM -0700, Andi Kleen wrote:
> > But none of this code uses RCU? I'm confused.
>
> There are two classes of callers: ones that change the maple tree while
> walking and those that don't. The ones that change it use
> kfree_rcu (if that's what you meant with "use RCU") because they can free
> nodes.
>
> The patch changes both classes, but strictly only the ones actually
> changing need the change. For the others the existing locking is
> indeed sufficient.

Andi I think you're really wildly off the mark here and it's not really a great
use of our time to help you debug your own private patch.

But in case you are on to a real bug here and I'm wildly wrong, it
shouldn't be difficult for you to point out precisely where the node is being
freed as a result of the split that causes a stale node to be referenced?

I mean what actually modifies the maple tree nodes here?

__split_vma()
  -> vma_complete()
    -> vma_iter_store_new()
      -> vma_iter_store_overwrite()

Right?

But I see:

	if (vmi->mas.status != ma_start &&
	    ((vmi->mas.index > vma->vm_start) || (vmi->mas.last < vma->vm_start)))
		vma_iter_invalidate(vmi);

Which calls mas_pause() which sets mas->node = NULL.

So I mean, presumably you are saying this doesn't work correctly or this
criteria is wrong, I can't really see how else there could be a problem here,
could you explain exactly what's up here?

Also why is the solution to insert a whole bunch of RCU read locks everywhere so
we can keep on accessing a node that we've already decided to free?

I mean surely the solution really ought to be simply invalidating the iterator
right?

Also again, could you share the patch you've applied to the kernel you're
actually seeing this bug in, given you haven't reproduced it even once with an
upstream kernel?

Thanks.

--
Cheers, Lorenzo