On 5/20/21 7:48 AM, Peter Xu wrote:

On Wed, May 19, 2021 at 10:16:07AM +0530, Aneesh Kumar K.V wrote:

quoted

quoted

On Thu, Apr 22, 2021 at 11:13:17AM +0530, Aneesh Kumar K.V wrote:

quoted

pmd/pud_populate is the right interface to be used to set the respective
page table entries. Some architectures like ppc64 do assume that set_pmd/pud_at
can only be used to set a hugepage PTE. Since we are not setting up a hugepage
PTE here, use the pmd/pud_populate interface.

[1]

quoted

Can you try this change?

modified   mm/mremap.c

@@ -279,7 +279,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
  	pmd_clear(old_pmd);
  
  	VM_BUG_ON(!pmd_none(*new_pmd));
-	pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
+	pmd_populate(mm, new_pmd, pmd_pgtable(pmd));
  
  	if (new_ptl != old_ptl)
  		spin_unlock(new_ptl);

I reported this issue today somewhere else:

https://lore.kernel.org/linux-mm/YKVemB5DuSqLFmmz@t490s/ (local)

And came to this same line after the bisection.

This seems to work at least for my userfaultfd test on shmem, however I don't
fully understand the commit message [1] on: How do we guarantee we're not
moving a thp pte?

move_page_tables() checks for pmd_trans_huge() and ends up calling 
move_huge_pmd if it is a THP entry.

-aneesh