Re: [PATCH v5 6/7] mm/maps: read proc/pid/maps under per-vma lock

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

This patch results in some spam :) there's a stray mmap_assert_locked() in
anon_vma_name() that triggers constantly.

Andrew - I attach a fix-patch for this, could you apply as at least a temporary
fix? As mm-new is broken at the moment with this patch.

Suren - could you check and obviously suggest something more sensible if you
feel this isn't right.

I'm not actually sure if we'd always have the VMA read lock here, maybe we need
an 'assert mmap lock or vma lock' predicate?

Worth auditing other mmap lock asserts that might have been missed with this
change also.

Cheers, Lorenzo

----8<----
From 1ed3bd12d43be1f8303fd6b7b714f5ef7e60728a Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Wed, 25 Jun 2025 13:28:36 +0100
Subject: [PATCH] mm/madvise: fixup stray mmap lock assert in anon_vma_name()

anon_vma_name() is being called under VMA lock, but is assert mmap lock which
won't necessarily be held.

This results in the kernel spamming warnings about this on startup.

Replace this with an open-coded 'mmap or VMA lock' assert to resolve.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
 mm/madvise.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index c467ee42596f..0530d033b3dd 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -108,7 +108,8 @@ void anon_vma_name_free(struct kref *kref)

 struct anon_vma_name *anon_vma_name(struct vm_area_struct *vma)
 {
-	mmap_assert_locked(vma->vm_mm);
+	if (!rwsem_is_locked(&vma->vm_mm->mmap_lock))
+		vma_assert_locked(vma);

 	return vma->anon_name;
 }
--
2.50.0