thp, khugepaged: skip retracting page table if a 64KB hugepage mapping is already... 81/265081/3
authorSung-hun Kim <sfoon.kim@samsung.com>
Wed, 6 Oct 2021 04:33:00 +0000 (13:33 +0900)
committerSung-hun Kim <sfoon.kim@samsung.com>
Tue, 12 Oct 2021 05:34:49 +0000 (14:34 +0900)
When khugepaged tries to retract page table entries,
an user can try to handle a page fault. To prevent
concurrent modifications for an address space, an
mmap_lock is used.

If khugepaged failed to get lock, it delays page
table retraction to the next interation. Previously,
however, khugepaged assumes that page table entries
have normal mapping, especially for 64KB hugepages.

This patch checks that a mapping is already
established for 64KB hugepage appropriately. If it is
khugepaged just skips a retraction.

Change-Id: I961e21e65e2ae09df43488582d1469e250059909
Signed-off-by: Sung-hun Kim <sfoon.kim@samsung.com>
mm/khugepaged.c

index 0622868..692b2fc 100644 (file)
@@ -1850,6 +1850,12 @@ void collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr)
                goto drop_hpage;
 
        start_pte = pte_offset_map_lock(mm, pmd, haddr, &ptl);
+#ifdef CONFIG_FINEGRAINED_THP
+       if (pte_cont(*start_pte)) {
+               pte_unmap_unlock(start_pte, ptl);
+               goto drop_hpage;
+       }
+#endif
 
        /* step 1: check all mapped PTEs are to the right huge page */
        for (i = 0, addr = haddr, pte = start_pte;