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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 844BCC43461 for ; Mon, 19 Apr 2021 16:41:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E010A611EE for ; Mon, 19 Apr 2021 16:41:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E010A611EE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgroup.eu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 811886B006E; Mon, 19 Apr 2021 12:41:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C2396B0070; Mon, 19 Apr 2021 12:41:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 627BA6B0071; Mon, 19 Apr 2021 12:41:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 4642F6B006E for ; Mon, 19 Apr 2021 12:41:20 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id EF8D92C81 for ; Mon, 19 Apr 2021 16:41:19 +0000 (UTC) X-FDA: 78049681878.09.DBAAED8 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf02.hostedemail.com (Postfix) with ESMTP id BDBB040002C3 for ; Mon, 19 Apr 2021 16:40:57 +0000 (UTC) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4FPCHr05Bbz9vBmZ; Mon, 19 Apr 2021 18:41:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id ByG0UeFaG4_7; Mon, 19 Apr 2021 18:41:11 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4FPCHq6Dlmz9vBmY; Mon, 19 Apr 2021 18:41:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 3D43E8B7C9; Mon, 19 Apr 2021 18:41:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id nDGl7TOpMiLz; Mon, 19 Apr 2021 18:41:17 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 56BD68B7C6; Mon, 19 Apr 2021 18:41:16 +0200 (CEST) Subject: Re: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage() To: Steven Price , 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> <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com> <627ee414-2f78-94e3-b77b-1013f52e77e3@csgroup.eu> <4a76fbda-aa9d-867b-e2eb-a1951780aeec@arm.com> From: Christophe Leroy Message-ID: <4cdd8dc0-34d6-11a3-f3b2-d6eb58c435c7@csgroup.eu> Date: Mon, 19 Apr 2021 18:41:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <4a76fbda-aa9d-867b-e2eb-a1951780aeec@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: BDBB040002C3 X-Stat-Signature: ek44uy4afzq3seebpyptz37a7pbtr6oj Received-SPF: none (csgroup.eu>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=pegase1.c-s.fr; client-ip=93.17.236.30 X-HE-DKIM-Result: none/none X-HE-Tag: 1618850457-992678 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: Le 19/04/2021 =C3=A0 16:00, Steven Price a =C3=A9crit=C2=A0: > On 19/04/2021 14:14, Christophe Leroy wrote: >> >> >> Le 16/04/2021 =C3=A0 12:51, Steven Price a =C3=A9crit=C2=A0: >>> On 16/04/2021 11:38, Christophe Leroy wrote: >>>> >>>> >>>> Le 16/04/2021 =C3=A0 11:28, Steven Price a =C3=A9crit=C2=A0: >>>>> On 15/04/2021 18:18, Christophe Leroy wrote: >>>>> >>>>> To be honest I don't fully understand why powerpc requires the page= _size - it appears to be=20 >>>>> using it purely to find "holes" in the calls to note_page(), but I = haven't worked out why such=20 >>>>> holes would occur. >>>> >>>> I was indeed introduced for KASAN. We have a first commit=20 >>>> https://github.com/torvalds/linux/commit/cabe8138 which uses page si= ze to detect whether it is a=20 >>>> KASAN like stuff. >>>> >>>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fi= x. I can't remember what the=20 >>>> problem was exactly, something around the use of hugepages for kerne= l memory, came as part of=20 >>>> the series=20 >>>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.158986= 6984.git.christophe.leroy@csgroup.eu/=20 >>> >>> >>> >>> >>> Ah, that's useful context. So it looks like powerpc took a different = route to reducing the KASAN=20 >>> output to x86. >>> >>> Given the generic ptdump code has handling for KASAN already it shoul= d be possible to drop that=20 >>> from the powerpc arch code, which I think means we don't actually nee= d to provide page size to=20 >>> notepage(). Hopefully that means more code to delete ;) >>> >> >> Looking at how the generic ptdump code handles KASAN, I'm a bit scepti= c. >> >> IIUC, it is checking that kasan_early_shadow_pte is in the same page a= s the pgtable referred by=20 >> the PMD entry. But what happens if that PMD entry is referring another= pgtable which is inside the=20 >> same page as kasan_early_shadow_pte ? >> >> Shouldn't the test be >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (pmd_page_vaddr(val) =3D=3D lm_alias(= kasan_early_shadow_pte)) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return note_kasan_pag= e_table(walk, addr); >=20 > Now I come to look at this code again, I think you're right. On arm64 t= his doesn't cause a problem -=20 > page tables are page sized and page aligned, so there couldn't be any n= on-KASAN pgtables sharing the=20 > page. Obviously that's not necessarily true of other architectures. >=20 > Feel free to add a patch to your series ;) >=20 Ok. I'll leave that outside of the series, it is not a show stopper because e= arly shadow page=20 directories are all tagged __bss_page_aligned so we can't have two of the= m in the same page and it=20 is really unlikely that we'll have any other statically defined page dire= ctory in the same pages either. And for the special case of powerpc 8xx which is the only one for which w= e have both KASAN and=20 HUGEPD at the time being, there are only two levels of page directories s= o no issue. Christophe