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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®