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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Mon, Oct 26, 2026 at 02:01:47PM -0400, Liam R. Howlett wrote:
> 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.

Ack, as discussed will give that a go and see how it looks taking on board
Suren's feedback also! :)

--
Cheers, Lorenzo