1. Patchew
  2. linux
  3. View series

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

kaleshsingh@google.com posted 1 patch 3 days, 19 hours ago 
fs/proc/task_mmu.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
[PATCH] mm: proc/task_mmu: Use walk_page_range_vma() for smaps
Posted by kaleshsingh@google.com 3 days, 19 hours ago 
From: Kalesh Singh <kaleshsingh@google.com>

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

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.

Fixes: ea3085dd7a4e ("fs/proc/task_mmu: read proc/pid/{smaps|numa_maps} under per-vma lock")
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
---
 fs/proc/task_mmu.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index d32408f7cd5e..5d301bdd05fc 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1369,9 +1369,12 @@ static void smap_gather_stats(struct proc_maps_private *priv,
 			      struct mem_size_stats *mss, unsigned long start)
 {
 	const struct mm_walk_ops *ops = get_smaps_walk_ops(priv);
+	unsigned long end = vma->vm_end;
+
+	start = start ?: vma->vm_start;
 
 	/* Invalid start */
-	if (start >= vma->vm_end)
+	if (start >= end)
 		return;
 
 	if (vma == get_gate_vma(priv->lock_ctx.mm))
@@ -1401,10 +1404,7 @@ static void smap_gather_stats(struct proc_maps_private *priv,
 		}
 	}
 
-	if (!start)
-		walk_page_vma(vma, ops, mss);
-	else
-		walk_page_range(vma->vm_mm, start, vma->vm_end, ops, mss);
+	walk_page_range_vma(vma, start, end, ops, mss);
 
 	reacquire_rcu(priv);
 }

base-commit: b95f03f04d475aa6719d15a636ddf32222d55657
-- 
2.55.0.229.g6434b31f56-goog
Re: [PATCH] mm: proc/task_mmu: Use walk_page_range_vma() for smaps
Posted by Andrew Morton 3 days ago 
On Tue, 21 Jul 2026 05:19:02 +0000 kaleshsingh@google.com wrote:

> From: Kalesh Singh <kaleshsingh@google.com>
> 
> 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?

> 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@google.com
Re: [PATCH] mm: proc/task_mmu: Use walk_page_range_vma() for smaps
Posted by Suren Baghdasaryan 2 days, 21 hours ago 
On Tue, Jul 21, 2026 at 5:39 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 21 Jul 2026 05:19:02 +0000 kaleshsingh@google.com wrote:
>
> > From: Kalesh Singh <kaleshsingh@google.com>
> >
> > 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@google.com
>
Re: [PATCH] mm: proc/task_mmu: Use walk_page_range_vma() for smaps
Posted by Kalesh Singh 2 days, 2 hours ago 
On Wed, Jul 22, 2026 at 12:17 PM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Tue, Jul 21, 2026 at 5:39 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Tue, 21 Jul 2026 05:19:02 +0000 kaleshsingh@google.com wrote:
> >
> > > From: Kalesh Singh <kaleshsingh@google.com>
> > >
> > > 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@google.com
> >
Re: [PATCH] mm: proc/task_mmu: Use walk_page_range_vma() for smaps
Posted by T.J. Mercier 3 days, 8 hours ago 
On Mon, Jul 20, 2026 at 10:19 PM kaleshsingh via kernel-team
<kernel-team@android.com> wrote:
>
> From: Kalesh Singh <kaleshsingh@google.com>
>
> 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).
>
> 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.
>
> Fixes: ea3085dd7a4e ("fs/proc/task_mmu: read proc/pid/{smaps|numa_maps} under per-vma lock")
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Liam R. Howlett <liam@infradead.org>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
> ---
>  fs/proc/task_mmu.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index d32408f7cd5e..5d301bdd05fc 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1369,9 +1369,12 @@ static void smap_gather_stats(struct proc_maps_private *priv,
>                               struct mem_size_stats *mss, unsigned long start)
>  {
>         const struct mm_walk_ops *ops = get_smaps_walk_ops(priv);
> +       unsigned long end = vma->vm_end;
> +
> +       start = start ?: vma->vm_start;

Doesn't overwriting start here break the !start && (!shmem_swapped ||
... check below when smap_gather_stats is called with start = 0 as in
show_smaps_rollup?

>
>         /* Invalid start */
> -       if (start >= vma->vm_end)
> +       if (start >= end)
>                 return;
>
>         if (vma == get_gate_vma(priv->lock_ctx.mm))
> @@ -1401,10 +1404,7 @@ static void smap_gather_stats(struct proc_maps_private *priv,
>                 }
>         }
>
> -       if (!start)
> -               walk_page_vma(vma, ops, mss);
> -       else
> -               walk_page_range(vma->vm_mm, start, vma->vm_end, ops, mss);
> +       walk_page_range_vma(vma, start, end, ops, mss);
>
>         reacquire_rcu(priv);
>  }
>
> base-commit: b95f03f04d475aa6719d15a636ddf32222d55657
> --
> 2.55.0.229.g6434b31f56-goog
>
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>
Re: [PATCH] mm: proc/task_mmu: Use walk_page_range_vma() for smaps
Posted by Kalesh Singh 3 days, 5 hours ago 
On Wed, Jul 22, 2026 at 1:30 AM T.J. Mercier <tjmercier@google.com> wrote:
>
> On Mon, Jul 20, 2026 at 10:19 PM kaleshsingh via kernel-team
> <kernel-team@android.com> wrote:
> >
> > From: Kalesh Singh <kaleshsingh@google.com>
> >
> > 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).
> >
> > 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.
> >
> > Fixes: ea3085dd7a4e ("fs/proc/task_mmu: read proc/pid/{smaps|numa_maps} under per-vma lock")
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Suren Baghdasaryan <surenb@google.com>
> > Cc: Liam R. Howlett <liam@infradead.org>
> > Cc: Lorenzo Stoakes <ljs@kernel.org>
> > Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
> > ---
> >  fs/proc/task_mmu.c | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index d32408f7cd5e..5d301bdd05fc 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -1369,9 +1369,12 @@ static void smap_gather_stats(struct proc_maps_private *priv,
> >                               struct mem_size_stats *mss, unsigned long start)
> >  {
> >         const struct mm_walk_ops *ops = get_smaps_walk_ops(priv);
> > +       unsigned long end = vma->vm_end;
> > +
> > +       start = start ?: vma->vm_start;
>
> Doesn't overwriting start here break the !start && (!shmem_swapped ||
> ... check below when smap_gather_stats is called with start = 0 as in
> show_smaps_rollup?

Hi Tj,

You are right, I should have updated it to start == vm_start. I will
fix this in v2.

Thanks,
Kalesh


>
> >
> >         /* Invalid start */
> > -       if (start >= vma->vm_end)
> > +       if (start >= end)
> >                 return;
> >
> >         if (vma == get_gate_vma(priv->lock_ctx.mm))
> > @@ -1401,10 +1404,7 @@ static void smap_gather_stats(struct proc_maps_private *priv,
> >                 }
> >         }
> >
> > -       if (!start)
> > -               walk_page_vma(vma, ops, mss);
> > -       else
> > -               walk_page_range(vma->vm_mm, start, vma->vm_end, ops, mss);
> > +       walk_page_range_vma(vma, start, end, ops, mss);
> >
> >         reacquire_rcu(priv);
> >  }
> >
> > base-commit: b95f03f04d475aa6719d15a636ddf32222d55657
> > --
> > 2.55.0.229.g6434b31f56-goog
> >
> > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
> >

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.