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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 29 Jan 2024 13:43:39 +0530 "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxx> 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?





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux