From: Matthew Wilcox <willy@infradead.org> To: Anshuman Khandual <anshuman.khandual@arm.com> Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Mark Brown <Mark.Brown@arm.com>, Steven Price <Steven.Price@arm.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Masahiro Yamada <yamada.masahiro@socionext.com>, Kees Cook <keescook@chromium.org>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, Sri Krishna chowdary <schowdary@nvidia.com>, Dave Hansen <dave.hansen@intel.com>, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] mm/pgtable/debug: Add test validating architecture page table helpers Date: Fri, 26 Jul 2019 12:54:57 -0700 [thread overview] Message-ID: <20190726195457.GI30641@bombadil.infradead.org> (raw) In-Reply-To: <c3bb0420-584c-de3b-2439-8702bc09595e@arm.com> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org> To: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Mark Rutland <mark.rutland@arm.com>, Kees Cook <keescook@chromium.org>, Sri Krishna chowdary <schowdary@nvidia.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Masahiro Yamada <yamada.masahiro@socionext.com>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, x86@kernel.org, Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org, Steven Price <Steven.Price@arm.com>, linux-mm@kvack.org, Mark Brown <Mark.Brown@arm.com>, Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC] mm/pgtable/debug: Add test validating architecture page table helpers Date: Fri, 26 Jul 2019 12:54:57 -0700 [thread overview] Message-ID: <20190726195457.GI30641@bombadil.infradead.org> (raw) In-Reply-To: <c3bb0420-584c-de3b-2439-8702bc09595e@arm.com> 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-07-26 19:55 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-25 6:55 [RFC] mm/debug: Add tests for architecture exported page table helpers Anshuman Khandual 2019-07-25 6:55 ` Anshuman Khandual 2019-07-25 6:55 ` [RFC] mm/pgtable/debug: Add test validating architecture " Anshuman Khandual 2019-07-25 6:55 ` Anshuman Khandual 2019-07-25 14:39 ` Matthew Wilcox 2019-07-25 14:39 ` Matthew Wilcox 2019-07-25 21:38 ` Russell King - ARM Linux admin 2019-07-25 21:38 ` Russell King - ARM Linux admin 2019-07-25 21:42 ` Matthew Wilcox 2019-07-25 21:42 ` Matthew Wilcox 2019-07-25 21:58 ` Russell King - ARM Linux admin 2019-07-25 21:58 ` Russell King - ARM Linux admin 2019-07-25 22:56 ` Matthew Wilcox 2019-07-25 22:56 ` Matthew Wilcox 2019-07-26 4:47 ` Anshuman Khandual 2019-07-26 4:47 ` Anshuman Khandual 2019-07-26 19:54 ` Matthew Wilcox [this message] 2019-07-26 19:54 ` Matthew Wilcox 2019-07-29 8:32 ` Anshuman Khandual 2019-07-29 8:32 ` Anshuman Khandual 2019-07-30 17:03 ` Matthew Wilcox 2019-07-30 17:03 ` Matthew Wilcox 2019-08-05 4:35 ` Anshuman Khandual 2019-08-05 4:35 ` Anshuman Khandual 2019-07-25 17:07 ` Catalin Marinas 2019-07-25 17:07 ` Catalin Marinas 2019-07-26 4:28 ` Anshuman Khandual 2019-07-26 4:28 ` Anshuman Khandual 2019-07-25 21:54 ` Russell King - ARM Linux admin 2019-07-25 21:54 ` Russell King - ARM Linux admin 2019-07-26 5:10 ` Anshuman Khandual 2019-07-26 5:10 ` Anshuman Khandual
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190726195457.GI30641@bombadil.infradead.org \ --to=willy@infradead.org \ --cc=Mark.Brown@arm.com \ --cc=Steven.Price@arm.com \ --cc=akpm@linux-foundation.org \ --cc=anshuman.khandual@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=dave.hansen@intel.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mark.rutland@arm.com \ --cc=mhocko@kernel.org \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=schowdary@nvidia.com \ --cc=x86@kernel.org \ --cc=yamada.masahiro@socionext.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.