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

[Suren Baghdasaryan]

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.

>
> > 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
>