On Wed, May 19, 2021 at 10:16:07AM +0530, Aneesh Kumar K.V wrote: > > On Thu, Apr 22, 2021 at 11:13:17AM +0530, Aneesh Kumar K.V wrote: > >> 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] > 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/ 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? -- Peter Xu
