Re: [PATCH 2/2] fs/proc/task_mmu: read proc/pid/smaps_rollup under per-vma lock

[Suren Baghdasaryan]

On Wed, Jun 10, 2026 at 8:02 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 6/10/26 16:56, Suren Baghdasaryan wrote:
> > On Wed, Jun 10, 2026 at 12:05 AM Lorenzo Stoakes <ljs@xxxxxxxxxx> wrote:
> >>
> >> On Tue, Jun 09, 2026 at 10:11:03AM -0700, Suren Baghdasaryan wrote:
> >>>
> >>> Ack.
> >>>
> >>>
> >>> Ack.
> >>>
> >>>
> >>> Sadly, for now we do (see my later comment).
> >>>
> >>>
> >>> It looked nicer I think :)
> >>
> >> Yeah tbh I think you're right
> >>
> >>>
> >>>
> >>> Ack.
> >>>
> >>>
> >>> We need it to avoid resetting vma_start, which is being reported even
> >>> when no normal VMAs are present.
> >>
> >> Well previously smap_gather_stats() would just be a no-op for a gate VMA, as it
> >> has:
> >>
> >>         if (vma == get_gate_vma(priv->lock_ctx.mm))
> >>                 return;
> >>
> >> Not sure if you'd have VMAs past that (is that even possible?) but in that case
> >> we would have set vma_start previously.
> >
> > I should explain this case in more detail. proc_get_vma() returns a
> > gate VMA once it finds no more VMAs. So, in this case if VMA tree is
> > empty, the first call to proc_get_vma() will return gate VMA. Now, the
> > original code was using vma_next() and would return NULL when the VMA
> > tree is empty and in that case it would bail out early here:
> > https://elixir.bootlin.com/linux/v7.1-rc7/source/fs/proc/task_mmu.c#L1423.
> > I need to use proc_get_vma() instead of vma_next() because it works
> > under RCU. So, the new code matches the previous behavior, but the
> > condition is different. I'll see if I can resolve this in a nicer way
> > but that's the gist of it.
>
> I guess some well-named helper that encapsulates the check would already help.
> But maybe the whole logic can be overhauled.

I'll see what makes more sense once the cleanups are in. Thanks!

>
> --
> Cheers,
>
> David