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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B47FCC02198 for ; Thu, 6 Feb 2025 04:22:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 270FD6B0085; Wed, 5 Feb 2025 23:22:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 222196B0088; Wed, 5 Feb 2025 23:22:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10FAA6B0089; Wed, 5 Feb 2025 23:22:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E901E6B0085 for ; Wed, 5 Feb 2025 23:21:59 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 719A2160EBA for ; Thu, 6 Feb 2025 04:21:59 +0000 (UTC) X-FDA: 83088221958.02.09D097B Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP id 524D920006 for ; Thu, 6 Feb 2025 04:21:57 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738815717; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AuAgdwDajVK2vGTyHl3+wr9kL1qPUEk2o7H/YzCfeIA=; b=TazS+AaLQ2JZNkg9LUewIuxXzfPiuJjKa/p6RxAxNPeYunTQfj8UmOE5IK2DpnZmMAMaT9 vMPSBaAXi1+ewiGta7Pg/NrbIPAMiVqa1pLjU1e/JnKjcdcC3boM4axP7+zNNekGaLPs+n vkQ2W05c5RujKcmDO8TAJE8gKThwNcY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738815717; a=rsa-sha256; cv=none; b=C91/kbRg6jdhdVnVgxLA66Y+XuvcisqiwOnWtOw29PbU6QA0+kb42gOgUkkimgiWu6A/mn p3Hu2R1dWGxYVtiu1OOayeR1aZ2OxcsW04QGHbay1iSxx9cP6LKl3x4Chsio3OCN4QHDKU VU3/BUi7OllY7gK6L+OAVpPIWRkDGhk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com 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 823831007; Wed, 5 Feb 2025 20:22:19 -0800 (PST) Received: from [10.163.34.115] (unknown [10.163.34.115]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F38B13F5A1; Wed, 5 Feb 2025 20:21:48 -0800 (PST) Message-ID: Date: Thu, 6 Feb 2025 09:51:45 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] mm/ptdump: Drop GENERIC_PTDUMP To: Mark Rutland Cc: linux-mm@kvack.org, steven.price@arm.com, christophe.leroy@csgroup.eu, Catalin Marinas , Will Deacon , Jonathan Corbet , Marc Zyngier , Michael Ellerman , Nicholas Piggin , Paul Walmsley , Palmer Dabbelt , Heiko Carstens , Vasily Gorbik , Thomas Gleixner , Ingo Molnar , Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org References: <20250205050039.1506377-1-anshuman.khandual@arm.com> Content-Language: en-US From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 524D920006 X-Stat-Signature: xtwshjy7aspofb5g1qtmfu14okxoy8cx X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1738815717-85184 X-HE-Meta: U2FsdGVkX1+BkRhqlAkDEnGmXiYahFRMZAPBr/qu6ia0PsaQKAnxxHE0JY+F3e7xLjPB/vWDzR6oboRBZMNoDZRnlpXUKu8JWVn169CNVM1AduF1HJeDyebWxDNtVhVlH/BGK0D9FLAmTXlwLxTkSjCTLXgbskTOuUaQgwZS1FK5/YcfkLX+zmnX+eCEfNyAd5OxR07h1iDCWfCpb5z/WMwngdW0SBrPZyEimkTPYkCCiQysaLl7NnSDYkKXkQjWtfmMjl6NThstS9KMsQrOGFGRyFerIf4Fmd7i885eJooQYfY9XzO6Wc9nFnbrRKnD5bFJRAymcVurUvD/yPD46sbtV1YGlbUzOFx6PoN4CdW3NTdLRJHj8gnJ66RjEAhnVfA68jLL3dHokEFkHa0A3y8OIvTbnjZs1oq7ryBxmk0Zdsot24xMuXtiGOwpJxtfv0qH4B0WvLTnAAvU3Qsglu8ZbBwAiUIVuJ7stGNNamPmmvLLfqZ13kZBHLjLYAVBrXsbTiWd9tYj5WFSiJ83yOYRUoCAhB/AxsvWhH/k+xKUZ33TX/plXoLXkoGPrJ38g8i2WE1XeY+yMStL660OeJ8hiT12T3YurN6BiLafnpZwKmFPj5Ny2IhG16GKAnJO7IEdi/hz25f6CG5aTYxlUDj3vkW/rz6FJjwsLM31V8Td20LjdnBq49Nkl8LaAz9w6TyMjolbRR7n2ioBq/3ikw1pHrGPxHNw59Ab08/QdNAsVzVKxYgB7gf5KZwYAgSFdMPSAwV7xpbMNS2oli4VFS+Ph+/xG4r2uQ1dXYTy6ZEjslmPyh8MJKhIFJcpRIxr4FIaDZXgca4IJ+mWg7YrVNKEFl0lcc6Jx26Ial7x9xu84XbBZCoDu/tuw8IoQRodH21XfWfpkdt/z7pA2lGQ65AyJxyvtFoHkRubfwsIQBhbzkuED0MQhZIhf9HGtRHtu0hX1qMu5fJwlIehDQU 0Kd+Vc0j 45HD/VUkvF2bi9MujUtd4skSF1dhSLWoxS69VpqJE8s3K+BCNm9cWH7mCihRUJZGQeD4xnDy4JioddSI2nJIJbzI0nRi1MtPauYSitHAQeYBFvS+JAZ/dLpcmtcdGnIDp/0QhzdCzB+L8BRDJLkxdPAd7CCRqbAtm3kTA9jwG/AFueu6fRSMIMpUOGeVZDD+OkRFsBNh2yqYQMBw9EdX5zZtdJ2PXqm5MuIcfJ+oadwIDonAe0YmZjuR2I2mjEH9lANrmMf4gjBCExmR9Mdq/PapJkfqAsMM9v4nmNNs6Z9EIuvYfX7SMujDwBkD/uxouSEYYdUe8oIwR6exalFw1pxsgLn4MoDaPPC1GSp3xW/qPCBth7gr09npSnUiMG2/KOgOiEs40Ba9LmJtzarFJLz/ZgKkp2D+tDET/5jTNg7jo388dLTCCM7jAap5tqUl57opPM8FkwQ7Xaj6fTjEVN1og8jqUsq3QJzcm1kyVR+KJX8kV1w8lJXYI6Mx1nIvHZWEQdvj8+xEfNgJlk2qw2caHErdE5iGF+ZFfjvpa3SIjFbixkAVkdV4eR71kSACNcvZP3odRtPVXppx1ag2qBVcFKMTPE3RdW7xhVzvEQdBIMYz2NK/IxN4j+Dw3fH9ydBQcBz+oYVlWxE/shVPFg7H+F29/vP6BvK0SEBa/kg3U1uOHFp6jxYSSFpdJoUPdxzVzGNJMkk+QaTq7RJVkBDAOCpUf9uteNzI5TnvPC6PZJ7HKobYUPF8DorqYRveQ53XC 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: List-Subscribe: List-Unsubscribe: On 2/5/25 15:31, Mark Rutland wrote: > On Wed, Feb 05, 2025 at 10:30:39AM +0530, Anshuman Khandual wrote: >> GENERIC_PTDUMP does not guard any code but instead just used for platform's >> subscription into core ptdump defined under PTDUMP_CORE, which is selected. > > Selected by what? I guess that sentence was incomplete. PTDUMP_CORE gets selected by all the real users which requires core PTDUMP to be built and enabled. arch/arm64/kvm/Kconfig: select PTDUMP_CORE /* config PTDUMP_STAGE2_DEBUGFS */ arch/x86/Kconfig.debug: select PTDUMP_CORE /* config EFI_PGT_DUMP */ mm/Kconfig.debug: select PTDUMP_CORE /* config PTDUMP_DEBUGFS */ mm/Kconfig.debug: select PTDUMP_CORE /* config DEBUG_WX */ > >> Instead use PTDUMP_CORE for platform subscription and drop GENERIC_PTDUMP. >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Jonathan Corbet >> Cc: Marc Zyngier >> Cc: Michael Ellerman >> Cc: Nicholas Piggin >> Cc: Paul Walmsley >> Cc: Palmer Dabbelt >> Cc: Heiko Carstens >> Cc: Vasily Gorbik >> Cc: Thomas Gleixner >> Cc: Ingo Molnar >> Cc: Andrew Morton >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: linux-doc@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> Cc: kvmarm@lists.linux.dev >> Cc: linuxppc-dev@lists.ozlabs.org >> Cc: linux-riscv@lists.infradead.org >> Cc: linux-s390@vger.kernel.org >> Cc: linux-mm@kvack.org >> Signed-off-by: Anshuman Khandual >> --- >> This patch applies on v6.14-rc1 >> >> Changes in V2: >> >> - Keep arch/powerpc/Kconfig alphabetically sorted per Christophe >> >> Changes in V1: >> >> https://lore.kernel.org/all/20241217034807.2541349-1-anshuman.khandual@arm.com/ >> >> Documentation/arch/arm64/ptdump.rst | 1 - >> arch/arm64/Kconfig | 2 +- >> arch/arm64/kvm/Kconfig | 3 +-- >> arch/powerpc/Kconfig | 2 +- >> arch/powerpc/configs/mpc885_ads_defconfig | 1 - >> arch/riscv/Kconfig | 2 +- >> arch/s390/Kconfig | 2 +- >> arch/x86/Kconfig | 2 +- >> arch/x86/Kconfig.debug | 2 +- >> kernel/configs/debug.config | 1 - >> mm/Kconfig.debug | 8 ++------ >> 11 files changed, 9 insertions(+), 17 deletions(-) >> >> diff --git a/Documentation/arch/arm64/ptdump.rst b/Documentation/arch/arm64/ptdump.rst >> index 5dcfc5d7cddf..61ca040a885b 100644 >> --- a/Documentation/arch/arm64/ptdump.rst >> +++ b/Documentation/arch/arm64/ptdump.rst >> @@ -22,7 +22,6 @@ offlining of memory being accessed by the ptdump code. >> In order to dump the kernel page tables, enable the following >> configurations and mount debugfs:: >> >> - CONFIG_GENERIC_PTDUMP=y >> CONFIG_PTDUMP_CORE=y >> CONFIG_PTDUMP_DEBUGFS=y >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index fcdd0ed3eca8..1f516bed81dd 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -157,7 +157,7 @@ config ARM64 >> select GENERIC_IRQ_SHOW_LEVEL >> select GENERIC_LIB_DEVMEM_IS_ALLOWED >> select GENERIC_PCI_IOMAP >> - select GENERIC_PTDUMP >> + select PTDUMP_CORE >> select GENERIC_SCHED_CLOCK >> select GENERIC_SMP_IDLE_THREAD >> select GENERIC_TIME_VSYSCALL > > This change means that the ptdump core code will be built regardless of > whether any users are selected: > > [mark@lakrids:~/src/linux]% git grep CONFIG_PTDUMP_CORE > Documentation/arch/arm64/ptdump.rst: CONFIG_PTDUMP_CORE=y > arch/arm64/include/asm/ptdump.h:#ifdef CONFIG_PTDUMP_CORE > arch/arm64/include/asm/ptdump.h:#endif /* CONFIG_PTDUMP_CORE */ > arch/arm64/mm/Makefile:obj-$(CONFIG_PTDUMP_CORE) += ptdump.o > arch/powerpc/mm/Makefile:obj-$(CONFIG_PTDUMP_CORE) += ptdump/ > arch/riscv/mm/Makefile:obj-$(CONFIG_PTDUMP_CORE) += ptdump.o > arch/s390/mm/Makefile:obj-$(CONFIG_PTDUMP_CORE) += dump_pagetables.o > arch/x86/mm/Makefile:obj-$(CONFIG_PTDUMP_CORE) += dump_pagetables.o > mm/Makefile:obj-$(CONFIG_PTDUMP_CORE) += ptdump.o > > GENERIC_PTDUMP means "this architecture uses generic ptdump code for > ptdump", i.e. the architecture implements all the necessary bits for > that to work *IF* it is built. > > PTDUMP_CORE means "actually build the core ptdump code". > > If everyone uses the generic ptdump code now, maybe it's worth renaming > GENERIC_PTDUMP to ARCH_HAS_PTDUMP or something like that, but I don't > think this change makes sense as-is. Seems like a combination of ARCH_HAS_CORE_PTDUMP for subscription and CORE_PTDUMP for actual enablement will make things clear. _CORE_ here would still let platforms define their own CONFIG_PTDUMP if preferred and not subscribe the generic CORE_DUMP. currently GENERIC_PTDUMP and CORE_PTDUMP just seems disjoint, because GENERIC_PTDUMP does not not appear to be the platform opt in required for CORE_PTDUMP. There is another problem. mm/Kconfig.debug config DEBUG_WX bool "Warn on W+X mappings at boot" depends on ARCH_HAS_DEBUG_WX depends on MMU select PTDUMP_CORE help Before selecting PTDUMP_CORE it does not ensure platform has opted in via GENERIC_PTDUMP or not. Instead it should be config DEBUG_WX bool "Warn on W+X mappings at boot" depends on ARCH_HAS_DEBUG_WX depends on GENERIC_PTDUMP depends on depends on MMU select PTDUMP_CORE help PTDUMP_STAGE2_DEBUGFS on arm64 does that where as EFI_PGT_DUMP on x86 does not. Although it will be ideal but that's not a problem if the platform knows for sure that it opts in GENERIC_PTDUMP. > > [...] > >> diff --git a/kernel/configs/debug.config b/kernel/configs/debug.config >> index 20552f163930..8aafd050b754 100644 >> --- a/kernel/configs/debug.config >> +++ b/kernel/configs/debug.config >> @@ -73,7 +73,6 @@ CONFIG_DEBUG_VM=y >> CONFIG_DEBUG_VM_PGFLAGS=y >> CONFIG_DEBUG_VM_RB=y >> CONFIG_DEBUG_VM_VMACACHE=y >> -CONFIG_GENERIC_PTDUMP=y >> CONFIG_KASAN=y >> CONFIG_KASAN_GENERIC=y >> CONFIG_KASAN_INLINE=y > > I think this is wrong today, and removing it is the right thing to do. > > Architectures with support will select this themselves, and on > architectures without support this either does nothing or causes a build > failure. Alright, will separate this change out first.