From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>,
"Liam R. Howlett" <liam@infradead.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Lance Yang <lance.yang@linux.dev>,
"David Hildenbrand (Arm)" <david@kernel.org>,
"Kiryl Shutsemau (Meta)" <kas@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Seunghyun An <san55@wisc.edu>
Subject: Re: [PATCH] mm/vma: predicate vma_assert_stabilised() on CONFIG_DEBUG_VM
Date: Wed, 11 Nov 2026 10:31:53 +0100 [thread overview]
Message-ID: <be5a0fa0-6299-4ccc-b9bf-adba7fca0208@kernel.org> (raw)
In-Reply-To: <20261110-vma-fixup-debug-asserts-v1-1-0b2e0680cd7e@kernel.org>
On 11/10/26 16:10, Lorenzo Stoakes (ARM) wrote:
> I introduced commit 17fd82c3abe0 ("mm/vma: add and use
> vma_assert_stabilised()") with the intent of picking up programmatic bugs
> when debugging mm code, but kept the general practice of asserting even
> when CONFIG_DEBUG_VM is not set in line with existing code.
>
> However, it turns out doing so can cause performance regressions,
> especially when asserted in vma_has_anon_rmap() which is referenced in a
> number of hotpaths.
>
> Since the intent was always a debug-only assertion, explicitly check for
> CONFIG_DEBUG_VM and do not assert if it isn't set.
>
> Really all of the assert paths need to be predicated on this, but start
> with this one only, out of caution.
>
> Additionally, since a detached VMA is trivially stabilised (nothing to
> stabilise against), check for this case at the outset, and update
> vma_has_anon_rmap() to not explicitly need to check for this.
>
> This also, importantly, avoids reading any VMA fields if CONFIG_DEBUG_VM is
> not set.
>
> Target the commit which introduced vma_has_anon_rmap() for the fix, as this
> is where the issue started manifesting in practice.
>
> Fixes: 38564710f443 ("mm: implement and use vma_has_anon_rmap(), silence KCSAN")
> Reported-by: Seunghyun An <san55@wisc.edu>
> Closes: https://lore.kernel.org/linux-mm/20261110000002.1834454-1-san55@wisc.edu/
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> Note that vma_is_anon_rmap() was introduced in 7.4, so no need for a cc: stable,
> just needs to be sent to Linus as a hotfix. Thanks!
> ---
> include/linux/mmap_lock.h | 19 ++++++++++++++-----
> mm/vma.h | 3 +--
> 2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
> index 9ccbbcbd7aca..9c3a9c6525c1 100644
> --- a/include/linux/mmap_lock.h
> +++ b/include/linux/mmap_lock.h
> @@ -408,6 +408,11 @@ static inline void vma_assert_locked(const struct vm_area_struct *vma)
> vma_assert_write_locked(vma);
> }
>
> +static inline bool vma_is_attached(const struct vm_area_struct *vma)
> +{
> + return refcount_read(&vma->vm_refcnt);
> +}
> +
> /**
> * vma_assert_stabilised() - assert that this VMA cannot be changed from
> * underneath us either by having a VMA or mmap lock held.
> @@ -418,9 +423,18 @@ static inline void vma_assert_locked(const struct vm_area_struct *vma)
> *
> * With lockdep disabled we may sometimes race with other threads acquiring the
> * mmap read lock simultaneous with our VMA read lock.
> + *
> + * Assert only if CONFIG_DEBUG_VM is set.
> */
> static inline void vma_assert_stabilised(const struct vm_area_struct *vma)
> {
> + if (!IS_ENABLED(CONFIG_DEBUG_VM))
> + return;
> +
> + /* Detached VMAs are trivially stabilised. */
> + if (!vma_is_attached(vma))
> + return;
> +
> /*
> * If another thread owns an mmap lock, it may go away at any time, and
> * thus is no guarantee of stability.
> @@ -454,11 +468,6 @@ static inline void vma_assert_stabilised(const struct vm_area_struct *vma)
> vma_assert_locked(vma);
> }
>
> -static inline bool vma_is_attached(const struct vm_area_struct *vma)
> -{
> - return refcount_read(&vma->vm_refcnt);
> -}
> -
> /*
> * WARNING: to avoid racing with vma_mark_attached()/vma_mark_detached(), these
> * assertions should be made either under mmap_write_lock or when the object
> diff --git a/mm/vma.h b/mm/vma.h
> index 3fc3b47a954b..05300badd70b 100644
> --- a/mm/vma.h
> +++ b/mm/vma.h
> @@ -278,8 +278,7 @@ static inline pgoff_t vmg_end_pgoff(const struct vma_merge_struct *vmg)
> */
> static inline bool vma_has_anon_rmap(const struct vm_area_struct *vma)
> {
> - if (vma_is_attached(vma))
> - vma_assert_stabilised(vma);
> + vma_assert_stabilised(vma);
> /* KCSAN gets confused about the optimistic check. Silence it. */
> return data_race(vma->anon_vma);
> }
>
> ---
> base-commit: 93d7a816a2df3e907e2719bd12b0073f1285fc5c
> change-id: 20261110-vma-fixup-debug-asserts-2d327fe27f8c
>
> Cheers,
prev parent reply other threads:[~2026-11-11 9:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 15:10 [PATCH] mm/vma: predicate vma_assert_stabilised() on CONFIG_DEBUG_VM Lorenzo Stoakes (ARM)
2026-11-10 15:18 ` Suren Baghdasaryan
2026-11-10 15:23 ` Liam R. Howlett
2026-11-10 15:37 ` Pedro Falcato
2026-11-10 16:07 ` Lorenzo Stoakes (ARM)
2026-11-10 16:18 ` Lorenzo Stoakes (ARM)
2026-11-10 16:39 ` Lorenzo Stoakes (ARM)
2026-11-10 17:32 ` Seunghyun An
2026-11-10 17:37 ` Lorenzo Stoakes (ARM)
2026-11-10 18:03 ` Seunghyun An
2026-11-10 18:07 ` Pedro Falcato
2026-11-11 9:31 ` Vlastimil Babka (SUSE) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=be5a0fa0-6299-4ccc-b9bf-adba7fca0208@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=pfalcato@suse.de \
--cc=san55@wisc.edu \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.