Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test

["Aneesh Kumar K.V" <aneesh.kumar@kernel.org>]

On 2/20/24 8:16 AM, Andrew Morton wrote:
> On Mon, 29 Jan 2024 13:43:39 +0530 "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
> 
>>>         return (pud_val(pud) & (_PAGE_PSE|_PAGE_DEVMAP)) == _PAGE_PSE;
>>> }
>>> #endif
>>>
>>> #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>>> static inline int pud_devmap(pud_t pud)
>>> {
>>>         return !!(pud_val(pud) & _PAGE_DEVMAP);
>>> }
>>> #else
>>> static inline int pud_devmap(pud_t pud)
>>> {
>>>         return 0;
>>> }
>>> #endif
>>>
>>> We might need some more clarity on this regarding x86 platform's pud huge
>>> page implementation.
>>>
>>
>> static vm_fault_t create_huge_pud(struct vm_fault *vmf)
>> {
>> #if defined(CONFIG_TRANSPARENT_HUGEPAGE) &&			\
>> 	defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
>> 	struct vm_area_struct *vma = vmf->vma;
>> 	/* No support for anonymous transparent PUD pages yet */
>> 	if (vma_is_anonymous(vma))
>> 		return VM_FAULT_FALLBACK;
>> 	if (vma->vm_ops->huge_fault)
>> 		return vma->vm_ops->huge_fault(vmf, PUD_ORDER);
>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>> 	return VM_FAULT_FALLBACK;
>> }
> 
> cryptic reply, unreplied to.
> 
> What's the thinking here?  Should we proceed with the patch as-is, or
> are changes needed?
> 

Sorry for the confusion. What i wanted to update with the code was to reiterate
that no architectures currently does anonymous pud hugepage. So restricting
debug_vm_pgtable pud hugepage test to devmap pte entries should be ok w.r.t
these tests.

-aneesh