[PATCH mm-unstable 1/1] fs/proc/task_mmu: advance seq_file position on interrupted VMA lookup

[PATCH mm-unstable 1/1] fs/proc/task_mmu: advance seq_file position on interrupted VMA lookup

[Adrian Huang (Lenovo)]

Commit 5631da56c9a8 ("fs/proc/task_mmu: read proc/pid/maps under
per-vma lock") introduced the possibility of returning -EINTR
from proc_get_vma() when the VMA lookup is interrupted.

When this happens in m_next(), proc_get_vma() returns an error
pointer without updating the position index. Consequently,
seq_read_iter() reports:

  seq_file: buggy .next function m_next did not update position index

The above buggy message is reproduced by the following command:

  # stress-ng --vma 0 -t 60

Update the position index when VMA lookup fails, as required by
the seq_file interface. Also save the original position in
priv->last_pos so that subsequent iteration can restart from
the correct address without skipping or repeating a VMA.

Fixes: 5631da56c9a8 ("fs/proc/task_mmu: read proc/pid/maps under per-vma lock")
Signed-off-by: Adrian Huang (Lenovo) <adrianhuang0701@gmail.com>
---
 fs/proc/task_mmu.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 22361607020d..164b4efc5e09 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -221,6 +221,16 @@ static struct vm_area_struct *proc_get_vma(struct seq_file *m, loff_t *ppos)
 		if (PTR_ERR(vma) == -EAGAIN && fallback_to_mmap_lock(priv, *ppos))
 			goto retry;
 
+		/*
+		 * seq_file checks that the position advanced before it looks at
+		 * the returned pointer, so an error return that leaves *ppos
+		 * alone is reported as a buggy ->next. Advance it, and keep
+		 * last_pos at the pending position so m_start() would resume
+		 * the lookup from there.
+		 */
+		priv->last_pos = *ppos;
+		(*ppos)++;
+
 		return vma;
 	}
 
-- 
2.43.0

Re: [PATCH mm-unstable 1/1] fs/proc/task_mmu: advance seq_file position on interrupted VMA lookup

[Andrew Morton]

On Thu, 12 Nov 2026 22:01:01 +0800 "Adrian Huang (Lenovo)" <adrianhuang0701@gmail.com> wrote:

> Commit 5631da56c9a8 ("fs/proc/task_mmu: read proc/pid/maps under
> per-vma lock") introduced the possibility of returning -EINTR
> from proc_get_vma() when the VMA lookup is interrupted.

OK, but what's causing the interruption?

> When this happens in m_next(), proc_get_vma() returns an error
> pointer without updating the position index. Consequently,
> seq_read_iter() reports:
> 
>   seq_file: buggy .next function m_next did not update position index
> 
> The above buggy message is reproduced by the following command:
> 
>   # stress-ng --vma 0 -t 60

afaict "stress-ng -t" can send SIGALRM, but mmap_read_lock_killable()
only responds to fatal signals.

So please clarify: exactly what is causing this to happen?

Re: [PATCH mm-unstable 1/1] fs/proc/task_mmu: advance seq_file position on interrupted VMA lookup

[Suren Baghdasaryan]

On Thu, Nov 12, 2026 at 6:37 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 12 Nov 2026 22:01:01 +0800 "Adrian Huang (Lenovo)" <adrianhuang0701@gmail.com> wrote:
>
> > Commit 5631da56c9a8 ("fs/proc/task_mmu: read proc/pid/maps under
> > per-vma lock") introduced the possibility of returning -EINTR
> > from proc_get_vma() when the VMA lookup is interrupted.
>
> OK, but what's causing the interruption?
>
> > When this happens in m_next(), proc_get_vma() returns an error
> > pointer without updating the position index. Consequently,
> > seq_read_iter() reports:
> >
> >   seq_file: buggy .next function m_next did not update position index
> >
> > The above buggy message is reproduced by the following command:
> >
> >   # stress-ng --vma 0 -t 60
>
> afaict "stress-ng -t" can send SIGALRM, but mmap_read_lock_killable()
> only responds to fatal signals.
>
> So please clarify: exactly what is causing this to happen?

Also I don't think stress-ng --vma 0 -t 60 command reads maps, smaps
or smaps_rollup files by itself but I might be mistaken. It would be
nice to get more details on how this gets reproduced.

>
>

Re: [PATCH mm-unstable 1/1] fs/proc/task_mmu: advance seq_file position on interrupted VMA lookup

[Suren Baghdasaryan]

On Thu, Nov 12, 2026 at 7:13 PM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Thu, Nov 12, 2026 at 6:37 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 12 Nov 2026 22:01:01 +0800 "Adrian Huang (Lenovo)" <adrianhuang0701@gmail.com> wrote:
> >
> > > Commit 5631da56c9a8 ("fs/proc/task_mmu: read proc/pid/maps under
> > > per-vma lock") introduced the possibility of returning -EINTR
> > > from proc_get_vma() when the VMA lookup is interrupted.
> >
> > OK, but what's causing the interruption?
> >
> > > When this happens in m_next(), proc_get_vma() returns an error
> > > pointer without updating the position index. Consequently,
> > > seq_read_iter() reports:
> > >
> > >   seq_file: buggy .next function m_next did not update position index
> > >
> > > The above buggy message is reproduced by the following command:
> > >
> > >   # stress-ng --vma 0 -t 60
> >
> > afaict "stress-ng -t" can send SIGALRM, but mmap_read_lock_killable()
> > only responds to fatal signals.
> >
> > So please clarify: exactly what is causing this to happen?
>
> Also I don't think stress-ng --vma 0 -t 60 command reads maps, smaps
> or smaps_rollup files by itself but I might be mistaken. It would be
> nice to get more details on how this gets reproduced.

Just after sending this I found
https://github.com/ColinIanKing/stress-ng/blob/master/stress-vma.c#L536,
so I stand corrected. Still, it would be nice to know how exactly this
issue is reproduced.

>
> >
> >