Re: [PATCH] fs/proc/task_mmu: fix missed VMAs when reading /proc/PID/maps and friends

[Liam R. Howlett]

On 26/10/26 05:26PM, Lorenzo Stoakes (ARM) wrote:
> On Mon, Oct 26, 2026 at 06:19:18PM +0100, David Hildenbrand (Arm) wrote:
> > >> +       /*
> > >> +        * No lock was held since the last call, so the iterator's cached range
> > >> +        * may no longer be valid. Always restart by address.
> > >> +        *
> > >> +        * The vma_range_is_empty() checks below avoid unnecessary mmap_lock
> > >> +        * fallbacks.
> > >> +        */
> > >> +       vma_iter_set(vmi, from_addr);
> > >
> > > This is clearly simpler but this unconditional vmi reset is not ideal.
> >
> > Yes, exactly how I ended up where we am right now.
> >
> > I pref my current fix as something to backport that avoids performance changes.
> >
> > If you two disagree, please take it over and drag it over the finishing line in
> > a timely manner.
> >
> > I wasted enough of my weekend with this over-enginered piece of software. (had
> > to change one word before sending, can you guess which :P )
> 
> No problem, will take over.
> 

Just a follow-up, another option: the vma iterator can check the
previous end from vm_end and set the maple state to the range of the
current vma if they disagree. Using the set_range() and not
__set_range(), so the next walk will be a new walk immediately.

Thanks,
Liam