[PATCH mm-hotfixes] mm: remove unnecessary and incorrect mmap lock assert

[PATCH mm-hotfixes] mm: remove unnecessary and incorrect mmap lock assert

[Lorenzo Stoakes]

This check was introduced by commit 42fc541404f2 ("mmap locking API: add
mmap_assert_locked() and mmap_assert_write_locked()") which replaced a
VM_BUG_ON_VMA() over rwsem_is_locked from commit a00cc7d9dd93 ("mm, x86:
add support for PUD-sized transparent hugepages"), i.e. the commit that
introduced PUD THPs.

These seem to be careful asserts introduced to ensure that locks are held
in general, however for a zap we require that VMAs are kept stable, and
this is a requirement that has held perfectly well for a long time.

These were long before VMA locks and thus there appears to be no reason to
think this is assert is there for anything other than 'stabilised VMA'.

Asserting that the VMA under examination is stable only in the case of a
THP PUD is strange and unnecessary. If we wish to be careful and assert
such things, we should do so at the zap level.

However in any case the current situation is already simply incorrect - a
VMA lock suffices here.

Remove the assert for now as it is unnecessarily, incorrect and unhelpful,
subsequent work can introduce an assert in general for zapping if required.

Fixes: 2ab7f1bbafc9 ("mm/madvise: allow guard page install/remove under VMA lock")
Reported-by: Chris Mason <clm@meta.com>
Closes: https://lore.kernel.org/all/20260113220856.2358195-1-clm@meta.com/
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
 mm/memory.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 4b0790c8fa48..6b22dd72ebc8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1963,10 +1963,9 @@ static inline unsigned long zap_pud_range(struct mmu_gather *tlb,
 	do {
 		next = pud_addr_end(addr, end);
 		if (pud_trans_huge(*pud)) {
-			if (next - addr != HPAGE_PUD_SIZE) {
-				mmap_assert_locked(tlb->mm);
+			if (next - addr != HPAGE_PUD_SIZE)
 				split_huge_pud(vma, pud, addr);
-			} else if (zap_huge_pud(tlb, vma, pud, addr))
+			else if (zap_huge_pud(tlb, vma, pud, addr))
 				goto next;
 			/* fall through */
 		}
--
2.52.0

Re: [PATCH mm-hotfixes] mm: remove unnecessary and incorrect mmap lock assert

[David Hildenbrand (Red Hat)]

On 1/14/26 12:56, Lorenzo Stoakes wrote:
> This check was introduced by commit 42fc541404f2 ("mmap locking API: add
> mmap_assert_locked() and mmap_assert_write_locked()") which replaced a
> VM_BUG_ON_VMA() over rwsem_is_locked from commit a00cc7d9dd93 ("mm, x86:
> add support for PUD-sized transparent hugepages"), i.e. the commit that
> introduced PUD THPs.
> 
> These seem to be careful asserts introduced to ensure that locks are held
> in general, however for a zap we require that VMAs are kept stable, and
> this is a requirement that has held perfectly well for a long time.
> 
> These were long before VMA locks and thus there appears to be no reason to
> think this is assert is there for anything other than 'stabilised VMA'.
> 
> Asserting that the VMA under examination is stable only in the case of a
> THP PUD is strange and unnecessary. If we wish to be careful and assert
> such things, we should do so at the zap level.
> 
> However in any case the current situation is already simply incorrect - a
> VMA lock suffices here.
> 
> Remove the assert for now as it is unnecessarily, incorrect and unhelpful,
> subsequent work can introduce an assert in general for zapping if required.
> 
> Fixes: 2ab7f1bbafc9 ("mm/madvise: allow guard page install/remove under VMA lock")
> Reported-by: Chris Mason <clm@meta.com>
> Closes: https://lore.kernel.org/all/20260113220856.2358195-1-clm@meta.com/
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

Makes sense to me

Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>

-- 
Cheers

David