From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755367AbdGXRy6 (ORCPT ); Mon, 24 Jul 2017 13:54:58 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34583 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753316AbdGXRyL (ORCPT ); Mon, 24 Jul 2017 13:54:11 -0400 Date: Mon, 24 Jul 2017 20:54:08 +0300 From: "Kirill A. Shutemov" To: Andrey Ryabinin Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, Dmitry Vyukov , Alexander Potapenko Subject: Re: [PATCH] x86/mm/dump_pagetables: Speed up page tables dump for CONFIG_KASAN=y Message-ID: <20170724175408.wry3krmzbb7y4jpi@node.shutemov.name> References: <20170724152558.24689-1-aryabinin@virtuozzo.com> <20170724153740.azg2x2xty2vowrmv@node.shutemov.name> <6cf8b23c-51ec-5a52-6ac9-0d3accf7e20b@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6cf8b23c-51ec-5a52-6ac9-0d3accf7e20b@virtuozzo.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 24, 2017 at 06:57:53PM +0300, Andrey Ryabinin wrote: > > > On 07/24/2017 06:37 PM, Kirill A. Shutemov wrote: > > On Mon, Jul 24, 2017 at 06:25:58PM +0300, Andrey Ryabinin wrote: > >> KASAN fills kernel page tables with repeated values to map several > >> TBs of the virtual memory to the single kasan_zero_page: > >> kasan_zero_p4d -> > >> kasan_zero_pud -> > >> kasan_zero_pmd-> > >> kasan_zero_pte-> > >> kasan_zero_page > >> > >> Walking the whole KASAN shadow range takes a lot of time, especially > >> with 5-level page tables. Since we already know that all kasan page tables > >> eventually point to the kasan_zero_page we could call note_page() > >> right and avoid walking lower levels of the page tables. > >> This will not affect the output of the kernel_page_tables file, > >> but let us avoid spending time in page table walkers: > >> > >> Before: > >> time cat /sys/kernel/debug/kernel_page_tables > /dev/null > >> > >> real 0m55.855s > >> user 0m0.000s > >> sys 0m55.840s > >> > >> After: > >> time cat /sys/kernel/debug/kernel_page_tables > /dev/null > >> > >> real 0m0.054s > >> user 0m0.000s > >> sys 0m0.054s > >> > >> Signed-off-by: Andrey Ryabinin > >> --- > >> arch/x86/mm/dump_pagetables.c | 64 +++++++++++++++++++++++++++---------------- > >> 1 file changed, 41 insertions(+), 23 deletions(-) > >> > >> diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c > >> index b371ab68f2d4..5e3ac6fe6c9e 100644 > >> --- a/arch/x86/mm/dump_pagetables.c > >> +++ b/arch/x86/mm/dump_pagetables.c > >> @@ -13,12 +13,12 @@ > >> */ > >> > >> #include > >> +#include > >> #include > >> #include > >> #include > >> #include > >> > >> -#include > >> #include > >> > >> /* > >> @@ -302,23 +302,53 @@ static void walk_pte_level(struct seq_file *m, struct pg_state *st, pmd_t addr, > >> start++; > >> } > >> } > >> +#ifdef CONFIG_KASAN > >> + > >> +/* > >> + * This is an optimization for KASAN=y case. Since all kasan page tables > >> + * eventually point to the kasan_zero_page we could call note_page() > >> + * right away without walking through lower level page tables. This saves > >> + * us dozens of seconds (minutes for 5-level config) while checking for > >> + * W+X mapping or reading kernel_page_tables debugfs file. > >> + */ > >> +static inline bool kasan_page_table(struct seq_file *m, struct pg_state *st, > >> + void *pt) > >> +{ > >> + if (__pa(pt) == __pa(kasan_zero_pmd) || > >> +#ifdef CONFIG_X86_5LEVEL > >> + __pa(pt) == __pa(kasan_zero_p4d) || > >> +#endif > >> + __pa(pt) == __pa(kasan_zero_pud)) { > >> + pgprotval_t prot = pte_flags(kasan_zero_pte[0]); > >> + note_page(m, st, __pgprot(prot), 5); > > > > Hm. I don't think '5' is correct here. Shouldn't it be dependent on what > > page table we detected? Or just take it from caller? > > > > No, 5 is correct, because all kasan page tables endup as a pte mapping of kasan_zero_page. > And pte is level 5. > > Anything but 5 would give us incorrect output in the last column in the last column of the dump, > pmd,pud or p4d instead of correct pte. > > Without the patch, if we stump on kasan page table we always endup with a note_page(..., 5) call. > With this patch we just avoid useless walks on lower levels of page tables, because we already know the end result, > so we just call note_page(.., 5) right away. You're right. Thanks for explanation. Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov