On Fri, Jul 26, 2019 at 10:17:11AM +0530, Anshuman Khandual wrote: > > But 'page' isn't necessarily PMD-aligned. I don't think we can rely on > > architectures doing the right thing if asked to make a PMD for a randomly > > aligned page. > > > > How about finding the physical address of something like kernel_init(), > > Physical address corresponding to the symbol in the kernel text segment ? Yes. We need the address of something that's definitely memory. The stack might be in vmalloc space. We can't allocate memory from the allocator that's PUD-aligned. This seems like a reasonable approximation to something that might work. > > and using the corresponding pte/pmd/pud/p4d/pgd that encompasses that > > So I guess this will help us use pte/pmd/pud/p4d/pgd entries from a real and > present mapping rather then making them up for test purpose. Although we are > not creating real page tables here just wondering if this could some how > affect these real mapping in anyway from some accessors. The current proposal > stays clear from anything real - allocates, evaluates and releases. I think that's a mistake. As Russell said, the ARM p*d manipulation functions expect to operate on tables, not on individual entries constructed on the stack. So I think the right thing to do here is allocate an mm, then do the pgd_alloc / p4d_alloc / pud_alloc / pmd_alloc / pte_alloc() steps giving you real page tables that you can manipulate. Then destroy them, of course. And don't access through them. > >> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD > >> +static void pud_basic_tests(void) > > > > Is this the right ifdef? > > IIUC THP at PUD is where the pud_t entries are directly operated upon and the > corresponding accessors are present only when HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD > is enabled. Am I missing something here ? Maybe I am. I thought we could end up operating on PUDs for kernel mappings, even without transparent hugepages turned on.
