Re: [PATCH] mm: proc/task_mmu: Use walk_page_range_vma() for smaps

[Kalesh Singh]

On Wed, Jul 22, 2026 at 12:17 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>
> On Tue, Jul 21, 2026 at 5:39 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, 21 Jul 2026 05:19:02 +0000 kaleshsingh@xxxxxxxxxx wrote:
> >
> > > From: Kalesh Singh <kaleshsingh@xxxxxxxxxx>
> > >
> > > Modify smap_gather_stats() to use walk_page_range_vma() instead of
> > > walk_page_range() when walking page tables.
> > >
> > > walk_page_range() internally calls find_vma(), which asserts that
> > > mmap_lock is held. This assertion fails when reading /proc/pid/smaps
> > > under per-VMA locks (where mmap_lock is not held).
> >
> > So the kernel is emitting a WARN trace under some situation?
> >
> > I'm surprised.  The offending patch is only six weeks old, but we'd
> > normally hear about this very promptly.   Is a bug report available
> > somewhere?
>
> No, when reading smaps "start" is always false, so walk_page_range()
> is never called.
> Kalesh, this is not a problem that ever happens in the upstream
> kernel. In Android kernel there was an out-of-tree change that caused
> this warning, which I pointed out and you fixed. However, the upstream
> kernel does not have this issue.

Hi Suren, thanks for the clarification.

Sorry for the confusion,  Andrew. Please ignore this patch.

Thanks,
Kalesh

>
> >
> > > walk_page_range_vma() walks a range within a single VMA and does not
> > > use find_vma(). It relies on the VMA lock instead (when configured
> > > with PGWALK_VMA_RDLOCK_VERIFY), making it compatible with per-VMA
> > > locks.
> >
> > Sashiko said a thing:
> >         https://sashiko.dev/#/patchset/20260721051903.691848-1-kaleshsingh@xxxxxxxxxx
> >