On Wed, Jul 9, 2025 at 1:57 AM Vlastimil Babka <[email protected]> wrote: > > On 7/8/25 01:10, Suren Baghdasaryan wrote: > >>> + rcu_read_unlock(); > >>> + vma = lock_vma_under_mmap_lock(mm, iter, address); > >>> + rcu_read_lock(); > >> OK I guess we hold the RCU lock the whole time as we traverse except when > >> we lock under mmap lock. > > Correct. > > I wonder if it's really necessary? Can't it be done just inside > lock_next_vma()? It would also avoid the unlock/lock dance quoted above. > > Even if we later manage to extend this approach to smaps and employ rcu > locking to traverse the page tables, I'd think it's best to separate and > fine-grain the rcu lock usage for vma iterator and page tables, if only to > avoid too long time under the lock.
I thought we would need to be in the same rcu read section while traversing the maple tree using vma_next() but now looking at it, maybe we can indeed enter only while finding and locking the next vma... Liam, would that work? I see struct ma_state containing a node field. Can it be freed from under us if we find a vma, exit rcu read section then re-enter rcu and use the same iterator to find the next vma?
