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