* + fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch added to mm-unstable branch
@ 2026-10-25 16:51 Andrew Morton
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2026-10-25 16:51 UTC (permalink / raw)
To: mm-commits, vbabka, surenb, stable, shakeel.butt, pfalcato, ljs,
liam, jannh, david, akpm
The patch titled
Subject: fs/proc/task_mmu: fix missed VMAs when reading /proc/PID/maps and friends
has been added to the -mm mm-unstable branch. Its filename is
fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: "David Hildenbrand (Arm)" <david@kernel.org>
Subject: fs/proc/task_mmu: fix missed VMAs when reading /proc/PID/maps and friends
Date: Sun, 25 Oct 2026 11:43:15 +0100
Reading /proc/PID/maps under per-VMA locks can skip continuously mapped
address ranges during concurrent VMA splits or merges. This violates the
guarantee in Documentation/filesystems/proc.rst:
"If there is something at a given vaddr during the entirety of the
life of the smaps/maps walk, there will be some output for it."
lock_next_vma() reuses a tree iterator across calls under RCU. The iterator
remembers the range of its last entry. When its node is replaced,
mas_next_slot() walks the tree again at the last index of that range, then
advances past the entry containing that index. If VMA boundaries changed,
this can skip a range that has not been reported:
- A lookup finds [A, C), then mprotect() splits it into [A, B) and [B, C)
before vma_start_read() locks the first VMA. The reader reports [A, B),
but the iterator still covers [A, C). The next call starts from B yet
advances past C, omitting [B, C).
- The reader reports [A, B) and unlocks it. A concurrent mprotect() then
merges it with [B, C). On the next call, the iterator resumes at B - 1,
which now belongs to [A, C), and advances past C. Again, [B, C) is lost.
Checking the mmap_lock sequence only within the next call misses writers
that completed before that call began. Also, a NULL result is currently
accepted without validation, so a race can terminate the walk early.
Even a fresh lookup can skip a mapping. Suppose it finds a gap before
[B, C). A writer inserts an adjacent VMA at the end of that gap, then
merges it into [B, C), replacing the node. The lookup resumes at the old
gap's last index, now inside the merged VMA, and steps past it. The
original [B, C) remains mapped throughout. Repeating the forward lookup
is insufficient: another merge can make it skip the same mapping again,
returning the same later VMA or NULL.
The fresh-lookup race also affects /proc/PID/smaps, numa_maps and
smaps_rollup. Resetting the iterator after gathering each VMA's statistics
does not prevent a merge during the next lookup. Fixing lock_next_vma()
also prevents omitted entries and incomplete rollup statistics.
Keep a saved sequence in the proc maps locking context and validate it
before each lookup with mmap_lock_speculate_retry(). If it is even (no
pending writer) and still matches, reuse both the iterator and the saved
sequence. Otherwise, restart at from_addr and sample the current sequence
before looking up the VMA. Only refresh the sample when resetting the
iterator, so a writer between validation and the lookup cannot go
undetected.
The smp_rmb() in mmap_lock_speculate_retry() orders the previous lookup
before rereading the sequence. It pairs with smp_wmb() in
do_raw_write_seqcount_begin(), which separates the sequence increment in
mmap_write_lock() from subsequent tree updates.
Validate detected gaps (from_addr < vma->vm_start) and NULL from
vma_next() against the sequence. If there were concurrent writes, use
mas_walk() to check if the writer could have interfered with the range
of interest. If the range is not empty, something interfered concurrently
so we retry under mmap_lock. Checking for empty ranges avoids taking the
mmap_lock just because an unrelated writer changed the sequence.
Original fix generated by an LLM and sent by Josef Bacik in private.
Link: https://lore.kernel.org/20261025-per_vma_maps-v1-1-c4eec45b9387@kernel.org
Fixes: 5631da56c9a8 ("fs/proc/task_mmu: read proc/pid/maps under per-vma lock")
Fixes: ea3085dd7a4e ("fs/proc/task_mmu: read proc/pid/{smaps|numa_maps} under per-vma lock")
Fixes: 0e985559d72a ("proc/task_mmu: read proc/pid/smaps_rollup under per-vma lock")
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Jann Horn <jannh@google.com>
Cc: Pedro Falcato <pfalcato@suse.de>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: <stable@vger.kernel.org>
---
fs/proc/internal.h | 1
fs/proc/task_mmu.c | 6 ++-
include/linux/mmap_lock.h | 5 +--
mm/mmap_lock.c | 58 ++++++++++++++++++++++++++----------
4 files changed, 51 insertions(+), 19 deletions(-)
--- a/fs/proc/internal.h~fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends
+++ a/fs/proc/internal.h
@@ -386,6 +386,7 @@ struct mem_size_stats;
struct proc_maps_locking_ctx {
struct mm_struct *mm;
bool mmap_locked;
+ unsigned int mm_wr_seq;
struct vm_area_struct *locked_vma;
};
--- a/fs/proc/task_mmu.c~fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends
+++ a/fs/proc/task_mmu.c
@@ -148,6 +148,7 @@ static void reset_lock_ctx(struct proc_m
{
lock_ctx->locked_vma = NULL;
lock_ctx->mmap_locked = false;
+ lock_ctx->mm_wr_seq = UINT_MAX;
}
static struct vm_area_struct *get_next_vma(struct proc_maps_private *priv,
@@ -160,7 +161,8 @@ static struct vm_area_struct *get_next_v
return vma_next(&priv->iter);
unlock_ctx_vma(lock_ctx);
- vma = lock_next_vma(lock_ctx->mm, &priv->iter, last_pos);
+ vma = lock_next_vma(lock_ctx->mm, &priv->iter, last_pos,
+ &lock_ctx->mm_wr_seq);
if (!IS_ERR_OR_NULL(vma))
lock_ctx->locked_vma = vma;
@@ -523,7 +525,7 @@ static struct vm_area_struct *query_vma_
unlock_ctx_vma(lock_ctx);
rcu_read_lock();
vma_iter_init(&vmi, mm, addr);
- vma = lock_next_vma(mm, &vmi, addr);
+ vma = lock_next_vma(mm, &vmi, addr, &lock_ctx->mm_wr_seq);
rcu_read_unlock();
if (!vma)
--- a/include/linux/mmap_lock.h~fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends
+++ a/include/linux/mmap_lock.h
@@ -513,12 +513,13 @@ struct vm_area_struct *lock_vma_under_rc
* Locks next vma pointed by the iterator. Confirms the locked vma has not
* been modified and will retry under mmap_lock protection if modification
* was detected. Should be called from read RCU section.
+ * *last_seq must initially be odd and is kept across calls.
* Returns either a valid locked VMA, NULL if no more VMAs or -EINTR if the
* process was interrupted.
*/
struct vm_area_struct *lock_next_vma(struct mm_struct *mm,
- struct vma_iterator *iter,
- unsigned long address);
+ struct vma_iterator *vmi, unsigned long from_addr,
+ unsigned int *last_seq);
static inline void vma_assert_can_modify(struct vm_area_struct *vma)
{
--- a/mm/mmap_lock.c~fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends
+++ a/mm/mmap_lock.c
@@ -428,21 +428,50 @@ static struct vm_area_struct *lock_next_
return vma;
}
+static bool vma_range_is_empty(struct mm_struct *mm, unsigned long start,
+ unsigned long last)
+{
+ MA_STATE(mas, &mm->mm_mt, start, start);
+
+ return !mas_walk(&mas) && mas.last >= last;
+}
+
struct vm_area_struct *lock_next_vma(struct mm_struct *mm,
- struct vma_iterator *vmi,
- unsigned long from_addr)
+ struct vma_iterator *vmi, unsigned long from_addr,
+ unsigned int *last_seq)
{
struct vm_area_struct *vma;
- unsigned int mm_wr_seq;
bool mmap_unlocked;
RCU_LOCKDEP_WARN(!rcu_read_lock_held(), "no rcu read lock held");
retry:
- /* Start mmap_lock speculation in case we need to verify the vma later */
- mmap_unlocked = mmap_lock_speculate_try_begin(mm, &mm_wr_seq);
+ /*
+ * Restart by address if a writer could have changed the cached range.
+ * The retry check's smp_rmb() orders the previous lookup before reading
+ * the sequence and pairs with smp_wmb() in do_raw_write_seqcount_begin().
+ *
+ * The vma_range_is_empty() checks below avoid unnecessary mmap_lock
+ * fallbacks.
+ */
+ mmap_unlocked = !(*last_seq & 1);
+ if (!mmap_unlocked || mmap_lock_speculate_retry(mm, *last_seq)) {
+ vma_iter_set(vmi, from_addr);
+ mmap_unlocked = mmap_lock_speculate_try_begin(mm, last_seq);
+ }
+
vma = vma_next(vmi);
- if (!vma)
- return NULL;
+ if (!vma) {
+ /*
+ * There is no reason to fallback if there really isn't anything
+ * in the remaining range.
+ */
+ if ((mmap_unlocked && !mmap_lock_speculate_retry(mm, *last_seq)) ||
+ vma_range_is_empty(mm, from_addr, ULONG_MAX))
+ return NULL;
+
+ rcu_read_unlock();
+ goto fallback;
+ }
vma = vma_start_read(mm, vma);
if (IS_ERR_OR_NULL(vma)) {
@@ -470,15 +499,14 @@ retry:
* it was not shrunk after we found it and another vma has not been
* installed ahead of it. Otherwise we might observe a gap that should
* not be there.
+ *
+ * If speculation fails, avoid taking the mmap_lock when a direct lookup
+ * confirms that the gap is empty.
*/
- if (from_addr < vma->vm_start) {
- /* Verify only if the address space might have changed since vma lookup. */
- if (!mmap_unlocked || mmap_lock_speculate_retry(mm, mm_wr_seq)) {
- vma_iter_set(vmi, from_addr);
- if (vma != vma_next(vmi))
- goto fallback_unlock;
- }
- }
+ if (from_addr < vma->vm_start &&
+ (!mmap_unlocked || mmap_lock_speculate_retry(mm, *last_seq)) &&
+ !vma_range_is_empty(mm, from_addr, vma->vm_start - 1))
+ goto fallback_unlock;
return vma;
_
Patches currently in -mm which might be from david@kernel.org are
mm-fix-address-wraparound-when-scanning-large-folio-ptes.patch
mm-hugetlb-disable-pmd-sharing-for-uffd-missing-mode.patch
mm-vma-write-lock-source-vma-before-duplicating-it-in-__split_vma.patch
mm-madvise-preserve-vma_softdirty_bit-when-changing-anonymous-names.patch
fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch
^ permalink raw reply [flat|nested] 2+ messages in thread
* + fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch added to mm-unstable branch
@ 2026-10-27 18:19 Andrew Morton
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2026-10-27 18:19 UTC (permalink / raw)
To: mm-commits, vbabka, surenb, stable, sj, shakeel.butt, pfalcato,
liam, jannh, david, ljs, akpm
The patch titled
Subject: fs/proc/task_mmu: fix missed VMAs when reading /proc/PID/maps and friends
has been added to the -mm mm-unstable branch. Its filename is
fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Subject: fs/proc/task_mmu: fix missed VMAs when reading /proc/PID/maps and friends
Date: Tue, 27 Oct 2026 14:08:26 +0000
Reading /proc/PID/maps under per-VMA locks can skip continuously mapped
address ranges during concurrent VMA splits or merges. This violates the
guarantee in Documentation/filesystems/proc.rst:
"If there is something at a given vaddr during the entirety of the
life of the smaps/maps walk, there will be some output for it."
lock_next_vma() reuses a tree iterator across calls under RCU. The iterator
remembers the range of its last entry. When its node is replaced,
mas_next_slot() walks the tree again at the last index of that range, then
advances past the entry containing that index. If VMA boundaries changed,
this can skip a range that has not been reported:
- A lookup finds [A, C), then mprotect() splits it into [A, B) and [B, C)
before vma_start_read() locks the first VMA. The reader reports [A, B),
but the iterator still covers [A, C). The next call starts from B yet
advances past C, omitting [B, C).
- The reader reports [A, B) and unlocks it. A concurrent mprotect() then
merges it with [B, C). On the next call, the iterator resumes at B - 1,
which now belongs to [A, C), and advances past C. Again, [B, C) is lost.
Checking the mmap_lock sequence only within the next call misses writers
that completed before that call began. Also, a NULL result is currently
accepted without validation, so a race can terminate the walk early.
Even a fresh lookup can skip a mapping. Suppose it finds a gap before
[B, C). A writer inserts an adjacent VMA at the end of that gap, then
merges it into [B, C), replacing the node. The lookup resumes at the old
gap's last index, now inside the merged VMA, and steps past it. The
original [B, C) remains mapped throughout. Repeating the forward lookup
is insufficient: another merge can make it skip the same mapping again,
returning the same later VMA or NULL.
The fresh-lookup race also affects /proc/PID/smaps, numa_maps and
smaps_rollup. Resetting the iterator after gathering each VMA's statistics
does not prevent a merge during the next lookup. Fixing lock_next_vma()
also prevents omitted entries and incomplete rollup statistics.
Tie VMA iterator state with the current mm and the write generation at the
point of last mm speculation in vma_rcu_iter, whose values we call 'rvmi'.
This allows us to neatly abstract the existing priv->iter logic alongside
query_vma_find_by_addr() which uses its own VMA iterator.
Then, provide helpers that act on the rvmi - vma_rcu_iter_[maybe_changed,
may_have_skipped]() to determine whether any VMAs may have
been altered since last mm speculation.
Additionally introduce vma_range_is_empty(), used by
vma_rcu_iter_may_have_skipped(), to determine conclusively whether VMAs
exist in a set range, needing to be traversed.
Original fix generated by an LLM and sent by Josef Bacik in private, then
amended by David Hildenbrand, and Lorenzo Stoakes added additional
abstraction.
Link: https://lore.kernel.org/20261027-fix-proc-pid-maps-missing-vmas-v2-1-2791cc9fc95f@kernel.org
Fixes: 5631da56c9a8 ("fs/proc/task_mmu: read proc/pid/maps under per-vma lock")
Fixes: ea3085dd7a4e ("fs/proc/task_mmu: read proc/pid/{smaps|numa_maps} under per-vma lock")
Fixes: 0e985559d72a ("proc/task_mmu: read proc/pid/smaps_rollup under per-vma lock")
Fixes: d9d1c2d81797 ("fs/proc/task_mmu: execute PROCMAP_QUERY ioctl under per-vma locks")
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Co-developed-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Jann Horn <jannh@google.com>
Cc: Pedro Falcato <pfalcato@suse.de>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: SJ Park <sj@kernel.org>
Cc: <stable@vger.kernel.org>
---
fs/proc/internal.h | 1
fs/proc/task_mmu.c | 13 ++++---
include/linux/mmap_lock.h | 22 +++++++++++-
mm/mmap_lock.c | 61 ++++++++++++++++++++++++++----------
4 files changed, 72 insertions(+), 25 deletions(-)
--- a/fs/proc/internal.h~fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends
+++ a/fs/proc/internal.h
@@ -393,6 +393,7 @@ struct proc_maps_private {
struct inode *inode;
struct task_struct *task;
struct vma_iterator iter;
+ struct vma_rcu_iter rvmi;
loff_t last_pos;
struct proc_maps_locking_ctx lock_ctx;
#ifdef CONFIG_NUMA
--- a/fs/proc/task_mmu.c~fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends
+++ a/fs/proc/task_mmu.c
@@ -160,7 +160,7 @@ static struct vm_area_struct *get_next_v
return vma_next(&priv->iter);
unlock_ctx_vma(lock_ctx);
- vma = lock_next_vma(lock_ctx->mm, &priv->iter, last_pos);
+ vma = lock_next_vma(&priv->rvmi, last_pos);
if (!IS_ERR_OR_NULL(vma))
lock_ctx->locked_vma = vma;
@@ -265,7 +265,7 @@ static void *m_start(struct seq_file *m,
*/
if (last_addr > 0)
*ppos = last_addr = priv->last_pos;
- vma_iter_init(&priv->iter, mm, (unsigned long)last_addr);
+ vma_rcu_iter_init(&priv->rvmi, mm, &priv->iter, (unsigned long)last_addr);
hold_task_mempolicy(priv);
/*
* If seq_file had to flush its collected data right after m_next() set
@@ -515,6 +515,7 @@ static struct vm_area_struct *query_vma_
struct mm_struct *mm = lock_ctx->mm;
struct vm_area_struct *vma;
struct vma_iterator vmi;
+ struct vma_rcu_iter rvmi;
if (lock_ctx->mmap_locked)
return find_vma(mm, addr);
@@ -522,8 +523,8 @@ static struct vm_area_struct *query_vma_
/* Unlock previously locked VMA and find the next one under RCU */
unlock_ctx_vma(lock_ctx);
rcu_read_lock();
- vma_iter_init(&vmi, mm, addr);
- vma = lock_next_vma(mm, &vmi, addr);
+ vma_rcu_iter_init(&rvmi, mm, &vmi, addr);
+ vma = lock_next_vma(&rvmi, addr);
rcu_read_unlock();
if (!vma)
@@ -1416,7 +1417,7 @@ static int show_smaps_rollup(struct seq_
rcu_read_lock();
reset_lock_ctx(lock_ctx);
- vma_iter_init(&priv->iter, mm, 0);
+ vma_rcu_iter_init(&priv->rvmi, mm, &priv->iter, 0);
vma = proc_get_vma(m, &pos);
if (unlikely(!vma))
goto empty_set;
@@ -1465,7 +1466,7 @@ static int show_smaps_rollup(struct seq_
reset_lock_ctx(lock_ctx);
/* Resume from the last position. */
pos = last_vma_end;
- vma_iter_init(&priv->iter, mm, pos);
+ vma_rcu_iter_init(&priv->rvmi, mm, &priv->iter, pos);
}
vma = proc_get_vma(m, &pos);
}
--- a/include/linux/mmap_lock.h~fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends
+++ a/include/linux/mmap_lock.h
@@ -17,6 +17,13 @@ extern int rcuwait_wake_up(struct rcuwai
#define MMAP_LOCK_INITIALIZER(name) \
.mmap_lock = __RWSEM_INITIALIZER((name).mmap_lock),
+/* Tie a VMA iterator to mm write lock state at iterator initialisation. */
+struct vma_rcu_iter {
+ struct mm_struct *mm;
+ struct vma_iterator *vmi;
+ unsigned int mm_wr_seq;
+};
+
DECLARE_TRACEPOINT(mmap_lock_start_locking);
DECLARE_TRACEPOINT(mmap_lock_acquire_returned);
DECLARE_TRACEPOINT(mmap_lock_released);
@@ -509,6 +516,16 @@ static inline void vma_mark_detached(str
struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
unsigned long address);
+static inline void vma_rcu_iter_init(struct vma_rcu_iter *rvmi,
+ struct mm_struct *mm, struct vma_iterator *vmi,
+ unsigned long addr)
+{
+ vma_iter_init(vmi, mm, addr);
+ rvmi->mm = mm;
+ rvmi->vmi = vmi;
+ rvmi->mm_wr_seq = UINT_MAX; /* Start odd so changed by default. */
+}
+
/*
* Locks next vma pointed by the iterator. Confirms the locked vma has not
* been modified and will retry under mmap_lock protection if modification
@@ -516,9 +533,8 @@ struct vm_area_struct *lock_vma_under_rc
* Returns either a valid locked VMA, NULL if no more VMAs or -EINTR if the
* process was interrupted.
*/
-struct vm_area_struct *lock_next_vma(struct mm_struct *mm,
- struct vma_iterator *iter,
- unsigned long address);
+struct vm_area_struct *lock_next_vma(struct vma_rcu_iter *rvmi,
+ unsigned long from_addr);
static inline void vma_assert_can_modify(struct vm_area_struct *vma)
{
--- a/mm/mmap_lock.c~fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends
+++ a/mm/mmap_lock.c
@@ -13,6 +13,8 @@
#include <linux/trace_events.h>
#include <linux/local_lock.h>
+#include "internal.h"
+
EXPORT_TRACEPOINT_SYMBOL(mmap_lock_start_locking);
EXPORT_TRACEPOINT_SYMBOL(mmap_lock_acquire_returned);
EXPORT_TRACEPOINT_SYMBOL(mmap_lock_released);
@@ -428,21 +430,53 @@ static struct vm_area_struct *lock_next_
return vma;
}
-struct vm_area_struct *lock_next_vma(struct mm_struct *mm,
- struct vma_iterator *vmi,
+/* Is there no VMA in [start, last]? */
+static bool vma_range_is_empty(struct mm_struct *mm, unsigned long start,
+ unsigned long last)
+{
+ VMA_ITERATOR(vmi, mm, start);
+
+ return !vma_iter_load(&vmi) && vma_iter_end(&vmi) - 1 >= last;
+}
+
+/* Might the VMA tree have been modified since last mm speculation? */
+static bool vma_rcu_iter_maybe_changed(const struct vma_rcu_iter *rvmi)
+{
+ return (rvmi->mm_wr_seq & 1) || /* Odd implies write-lock. */
+ mmap_lock_speculate_retry(rvmi->mm, rvmi->mm_wr_seq);
+}
+
+/* Could the VMA iterator have skipped a VMA due to the tree changing? */
+static bool vma_rcu_iter_may_have_skipped(const struct vma_rcu_iter *rvmi,
+ unsigned long from, unsigned long to)
+{
+ return vma_rcu_iter_maybe_changed(rvmi) &&
+ !vma_range_is_empty(rvmi->mm, from, to);
+}
+
+struct vm_area_struct *lock_next_vma(struct vma_rcu_iter *rvmi,
unsigned long from_addr)
{
+ struct mm_struct *mm = rvmi->mm;
+ struct vma_iterator *vmi = rvmi->vmi;
struct vm_area_struct *vma;
- unsigned int mm_wr_seq;
- bool mmap_unlocked;
RCU_LOCKDEP_WARN(!rcu_read_lock_held(), "no rcu read lock held");
retry:
- /* Start mmap_lock speculation in case we need to verify the vma later */
- mmap_unlocked = mmap_lock_speculate_try_begin(mm, &mm_wr_seq);
+ /* Only trust the iterator's position if the tree cannot have changed. */
+ if (vma_rcu_iter_maybe_changed(rvmi)) {
+ vma_iter_set(vmi, from_addr);
+ mmap_lock_speculate_try_begin(mm, &rvmi->mm_wr_seq);
+ }
vma = vma_next(vmi);
- if (!vma)
- return NULL;
+ if (!vma) {
+ /* No reason to fallback if nothing left in range. */
+ if (!vma_rcu_iter_may_have_skipped(rvmi, from_addr, ULONG_MAX))
+ return NULL;
+
+ rcu_read_unlock();
+ goto fallback;
+ }
vma = vma_start_read(mm, vma);
if (IS_ERR_OR_NULL(vma)) {
@@ -471,14 +505,9 @@ retry:
* installed ahead of it. Otherwise we might observe a gap that should
* not be there.
*/
- if (from_addr < vma->vm_start) {
- /* Verify only if the address space might have changed since vma lookup. */
- if (!mmap_unlocked || mmap_lock_speculate_retry(mm, mm_wr_seq)) {
- vma_iter_set(vmi, from_addr);
- if (vma != vma_next(vmi))
- goto fallback_unlock;
- }
- }
+ if (from_addr < vma->vm_start &&
+ vma_rcu_iter_may_have_skipped(rvmi, from_addr, vma->vm_start - 1))
+ goto fallback_unlock;
return vma;
_
Patches currently in -mm which might be from ljs@kernel.org are
mm-vma-fix-expansion-of-vma_mixedmap_bit-vmas.patch
mm-do-not-unintentionally-overwrite-atomic-vma-flags.patch
mm-vma-avoid-losing-atomic-vma-flags-when-setting-sticky-vma-flags.patch
mm-vma-update-vma-iterator-state-on-error-in-new-vma-merge.patch
fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-10-27 18:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-25 16:51 + fs-proc-task_mmu-fix-missed-vmas-when-reading-proc-pid-maps-and-friends.patch added to mm-unstable branch Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2026-10-27 18:19 Andrew Morton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.