From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-20.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FEFBC43462 for ; Fri, 16 Apr 2021 10:51:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C6C2D6115B for ; Fri, 16 Apr 2021 10:51:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C6C2D6115B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 404CA6B0036; Fri, 16 Apr 2021 06:51:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38DFE6B006C; Fri, 16 Apr 2021 06:51:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 207C86B0070; Fri, 16 Apr 2021 06:51:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id 010BB6B0036 for ; Fri, 16 Apr 2021 06:51:22 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A50142C37 for ; Fri, 16 Apr 2021 10:51:22 +0000 (UTC) X-FDA: 78037913604.05.BC41C4C Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf22.hostedemail.com (Postfix) with ESMTP id ADC97C0007C0 for ; Fri, 16 Apr 2021 10:51:17 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 31375106F; Fri, 16 Apr 2021 03:51:21 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6D9123F85F; Fri, 16 Apr 2021 03:51:19 -0700 (PDT) Subject: Re: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage() To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , akpm@linux-foundation.org Cc: linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-mm@kvack.org References: <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu> <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com> From: Steven Price Message-ID: <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com> Date: Fri, 16 Apr 2021 11:51:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB X-Stat-Signature: 7iyf9d65868wcwif84ptuadet9jbrrbw X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: ADC97C0007C0 Received-SPF: none (arm.com>: No applicable sender policy available) receiver=imf22; identity=mailfrom; envelope-from=""; helo=foss.arm.com; client-ip=217.140.110.172 X-HE-DKIM-Result: none/none X-HE-Tag: 1618570277-744155 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 16/04/2021 11:38, Christophe Leroy wrote: >=20 >=20 > Le 16/04/2021 =C3=A0 11:28, Steven Price a =C3=A9crit=C2=A0: >> On 15/04/2021 18:18, Christophe Leroy wrote: >>> In order to support large pages on powerpc, notepage() >>> needs to know the page size of the page. >>> >>> Add a page_size argument to notepage(). >>> >>> Signed-off-by: Christophe Leroy >>> --- >>> =C2=A0 arch/arm64/mm/ptdump.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0 2 +- >>> =C2=A0 arch/riscv/mm/ptdump.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0 2 +- >>> =C2=A0 arch/s390/mm/dump_pagetables.c |=C2=A0 3 ++- >>> =C2=A0 arch/x86/mm/dump_pagetables.c=C2=A0 |=C2=A0 2 +- >>> =C2=A0 include/linux/ptdump.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0 2 +- >>> =C2=A0 mm/ptdump.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 16 ++++= ++++-------- >>> =C2=A0 6 files changed, 14 insertions(+), 13 deletions(-) >>> >> [...] >>> diff --git a/mm/ptdump.c b/mm/ptdump.c >>> index da751448d0e4..61cd16afb1c8 100644 >>> --- a/mm/ptdump.c >>> +++ b/mm/ptdump.c >>> @@ -17,7 +17,7 @@ static inline int note_kasan_page_table(struct=20 >>> mm_walk *walk, >>> =C2=A0 { >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct ptdump_state *st =3D walk->priv= ate; >>> -=C2=A0=C2=A0=C2=A0 st->note_page(st, addr, 4, pte_val(kasan_early_sh= adow_pte[0])); >>> +=C2=A0=C2=A0=C2=A0 st->note_page(st, addr, 4, pte_val(kasan_early_sh= adow_pte[0]),=20 >>> PAGE_SIZE); >> >> I'm not completely sure what the page_size is going to be used for,=20 >> but note that KASAN presents an interesting case here. We short-cut by= =20 >> detecting it's a KASAN region at a high level (PGD/P4D/PUD/PMD) and=20 >> instead of walking the tree down just call note_page() *once* but with= =20 >> level=3D=3D4 because we know KASAN sets up the page table like that. >> >> However the one call actually covers a much larger region - so while=20 >> PAGE_SIZE matches the level it doesn't match the region covered.=20 >> AFAICT this will lead to odd results if you enable KASAN on powerpc. >=20 > Hum .... I successfully tested it with KASAN, I now realise that I=20 > tested it with CONFIG_KASAN_VMALLOC selected. In this situation, since=20 > https://github.com/torvalds/linux/commit/af3d0a686 we don't have any=20 > common shadow page table anymore. >=20 > I'll test again without CONFIG_KASAN_VMALLOC. >=20 >> >> To be honest I don't fully understand why powerpc requires the=20 >> page_size - it appears to be using it purely to find "holes" in the=20 >> calls to note_page(), but I haven't worked out why such holes would=20 >> occur. >=20 > I was indeed introduced for KASAN. We have a first commit=20 > https://github.com/torvalds/linux/commit/cabe8138 which uses page size=20 > to detect whether it is a KASAN like stuff. >=20 > Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. = I=20 > can't remember what the problem was exactly, something around the use o= f=20 > hugepages for kernel memory, came as part of the series=20 > https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.158986698= 4.git.christophe.leroy@csgroup.eu/=20 Ah, that's useful context. So it looks like powerpc took a different=20 route to reducing the KASAN output to x86. Given the generic ptdump code has handling for KASAN already it should=20 be possible to drop that from the powerpc arch code, which I think means=20 we don't actually need to provide page size to notepage(). Hopefully=20 that means more code to delete ;) Steve