s390/mm: Add mmap_assert_write_locked() check to crst_table_upgrade()
authorHeiko Carstens <hca@linux.ibm.com>
Wed, 30 Apr 2025 08:59:30 +0000 (10:59 +0200)
committerHeiko Carstens <hca@linux.ibm.com>
Mon, 5 May 2025 13:47:20 +0000 (15:47 +0200)
Add mmap_assert_write_locked() check to crst_table_upgrade() in order to
verify that no concurrent page table upgrades of an mm can happen. This
allows to remove the VM_BUG_ON() check which checks for the potential
inconsistent result of concurrent updates.

Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
arch/s390/mm/pgalloc.c

index 9470280831d826ce372ef9a34df2c8003e3c0f39..e33903b419a93f799a0e64dfc85e1bf86702ab25 100644 (file)
@@ -56,6 +56,8 @@ int crst_table_upgrade(struct mm_struct *mm, unsigned long end)
        unsigned long *pgd = NULL, *p4d = NULL, *__pgd;
        unsigned long asce_limit = mm->context.asce_limit;
 
+       mmap_assert_write_locked(mm);
+
        /* upgrade should only happen from 3 to 4, 3 to 5, or 4 to 5 levels */
        VM_BUG_ON(asce_limit < _REGION2_SIZE);
 
@@ -79,13 +81,6 @@ int crst_table_upgrade(struct mm_struct *mm, unsigned long end)
 
        spin_lock_bh(&mm->page_table_lock);
 
-       /*
-        * This routine gets called with mmap_lock lock held and there is
-        * no reason to optimize for the case of otherwise. However, if
-        * that would ever change, the below check will let us know.
-        */
-       VM_BUG_ON(asce_limit != mm->context.asce_limit);
-
        if (p4d) {
                __pgd = (unsigned long *) mm->pgd;
                p4d_populate(mm, (p4d_t *) p4d, (pud_t *) __pgd);