Re: [PATCH] mm/mmap_lock: Reset maple state on lock_vma_under_rcu() retry

[Vlastimil Babka <vbabka@suse.cz>]

(sorry for the late reply)

On 11/13/25 12:05, Lorenzo Stoakes wrote:
>> > > I think one source of confusion for me with maple tree operations is - what
>> > > to do if we are in a position where some kind of reset is needed?
>> > >
>> > > So even if I'd realised 'aha we need to reset this' it wouldn't be obvious
>> > > to me that we ought to set to the address.
>> >
>> > I think that's a separate problem.
>> >
>> > > > +++ b/mm/mmap_lock.c
>> > > > @@ -257,6 +257,7 @@ struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
>> > > >  		if (PTR_ERR(vma) == -EAGAIN) {
>> > > >  			count_vm_vma_lock_event(VMA_LOCK_MISS);
>> > > >  			/* The area was replaced with another one */
>> > > > +			mas_set(&mas, address);
>> > >
>> > > I wonder if we could detect that the RCU lock was released (+ reacquired) in
>> > > mas_walk() in a debug mode, like CONFIG_VM_DEBUG_MAPLE_TREE?
>> >
>> > Dropping and reacquiring the RCU read lock should have been a big red
>> > flag.  I didn't have time to review the patches, but if I had, I would
>> > have suggested passing the mas down to the routine that drops the rcu
>> > read lock so it can be invalidated before dropping the readlock.
>>
>> There has been some academic efforts to check for RCU-protected pointers
>> leaking from one RCU read-side critical section to another, but nothing
>> useful has come from this.  :-/
> 
> Ugh a pity. I was hoping we could do (in debug mode only obv) something
> absolutely roughly like:
> 
> On init:
> 
> mas->rcu_critical_section = rcu_get_critical_section_blah();

AFAICT, get_state_synchronize_rcu()?

> ...
> 
> On walk:
> 
> 	VM_WARN_ON(rcu_critical_section_blah() != mas->rcu_critical_section);

And here, poll_state_synchronize_rcu()?

It wouldn't detect directly that we dropped and reacquired the rcu read
lock, but with enough testing, that would at some point translate to a new
grace period between the first and second read lock, and we'd catch it then?

> But sounds like that isn't feasible.
I don't think what Paul says means your suggestion is not feasible. I think
he says there are no known ways to do this checking automagicallt. But your
suggestion is doing it manually for a specific case. I guess it depends on
how many maple tree functions we'd have to change and how ugly it would be.

> I always like the idea of us having debug stuff that helps highlight dumb
> mistakes very quickly, no matter how silly they might be :)
> 
>>
>> But rcu_pointer_handoff() and unrcu_pointer() are intended not only for
>> documentation, but also to suppress the inevitable false positives should
>> anyone figure out how to detect leaking of RCU-protected pointers.
>>
>> 							Thanx, Paul
> 
> Cheers, Lorenzo