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 2CDCBC3ABD8 for ; Fri, 16 May 2025 15:28:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D14F6B019F; Fri, 16 May 2025 11:28:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A8A86B01A0; Fri, 16 May 2025 11:28:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14B106B01A1; Fri, 16 May 2025 11:28:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E609D6B019F for ; Fri, 16 May 2025 11:28:28 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EC30C1A09F9 for ; Fri, 16 May 2025 15:28:29 +0000 (UTC) X-FDA: 83449152738.26.AEAD016 Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) by imf19.hostedemail.com (Postfix) with ESMTP id 86E1C1A000E for ; Fri, 16 May 2025 15:28:27 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=amazon.de header.s=amazoncorp2 header.b=nubmEBDS; spf=pass (imf19.hostedemail.com: domain of "prvs=2246ff648=ptyadav@amazon.de" designates 52.95.48.154 as permitted sender) smtp.mailfrom="prvs=2246ff648=ptyadav@amazon.de"; dmarc=pass (policy=quarantine) header.from=amazon.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747409307; a=rsa-sha256; cv=none; b=hlQEu2kQhjDrVeu59bL76FiXAi5V2ER9gMrQvTWXj85WwCeLUdMMvp+ch2rTGxcB94xyU4 NatruNLOkclWL/XWkIrR7986MTXTqQX/MnmKDhxwM01byLgkXV5Uv5igiVBSGqK1VPqvy1 cUPh/ZS/6kjMpalnET2OFmtZkMj730M= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=amazon.de header.s=amazoncorp2 header.b=nubmEBDS; spf=pass (imf19.hostedemail.com: domain of "prvs=2246ff648=ptyadav@amazon.de" designates 52.95.48.154 as permitted sender) smtp.mailfrom="prvs=2246ff648=ptyadav@amazon.de"; dmarc=pass (policy=quarantine) header.from=amazon.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747409307; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/YGeJfXKIquYSt90tYMJ+el7wnECiC9xpMwa6JMR6os=; b=OuU01uiTr/uYDH1kNN2Y/EOwZY5j4UdRfzzW5Jj2VqgF5VlBb776Kgj70BgVn1PXm/nF46 siTJ0XhVsNd2rld5B9qs05CTuqFb0fAUwsS69SH1ydV4GUIAzzNnwGa+aiDMRz+CBV7BZa GsfQ4Yly/kNSSH+KaCkGBRdpjm5zuqk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazoncorp2; t=1747409308; x=1778945308; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=/YGeJfXKIquYSt90tYMJ+el7wnECiC9xpMwa6JMR6os=; b=nubmEBDSVR4kf7Ll/DymsGk2hPxu6OkonUNThJo07qmSY1GaKEUFDm49 BZ4hetAsmrsMrCuDYSEEGzOVpaZoy1Iy6xDH7ArV8EZ363nNorM6EL8W9 /0Asg/hPfHk0jHe+3My9uHrWEXMXra/JaDqaVT3uujfiEUpQg6r9rl/Ie qrIdB84CqBjqF9fUiU6KqNlPEtzDKsICzkoxRl7zDsR5eI5sabyXCZVsg ZjOXcw/N3rMUxADuJydc3JilDJ6Z3XzipNkEro4bTSd3jMFpDTg8O25yT 0D8x879qtfFp7QrxWH+epDWb9i2wxocEixJY2qvK3HtK7uonkZOMywEen g==; X-IronPort-AV: E=Sophos;i="6.15,294,1739836800"; d="scan'208";a="490816896" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.43.8.2]) by smtp-border-fw-6001.iad6.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2025 15:28:24 +0000 Received: from EX19MTAEUC001.ant.amazon.com [10.0.43.254:48579] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.40.19:2525] with esmtp (Farcaster) id 8875e536-5df1-4a46-a9d9-d4740a3f3911; Fri, 16 May 2025 15:28:23 +0000 (UTC) X-Farcaster-Flow-ID: 8875e536-5df1-4a46-a9d9-d4740a3f3911 Received: from EX19D039EUA004.ant.amazon.com (10.252.50.95) by EX19MTAEUC001.ant.amazon.com (10.252.51.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1544.14; Fri, 16 May 2025 15:28:20 +0000 Received: from EX19MTAUWA001.ant.amazon.com (10.250.64.204) by EX19D039EUA004.ant.amazon.com (10.252.50.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1544.14; Fri, 16 May 2025 15:28:19 +0000 Received: from email-imr-corp-prod-iad-all-1a-6ea42a62.us-east-1.amazon.com (10.25.36.214) by mail-relay.amazon.com (10.250.64.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1544.14 via Frontend Transport; Fri, 16 May 2025 15:28:18 +0000 Received: from dev-dsk-ptyadav-1c-43206220.eu-west-1.amazon.com (dev-dsk-ptyadav-1c-43206220.eu-west-1.amazon.com [172.19.91.144]) by email-imr-corp-prod-iad-all-1a-6ea42a62.us-east-1.amazon.com (Postfix) with ESMTP id CD1C2401B0; Fri, 16 May 2025 15:28:17 +0000 (UTC) Received: by dev-dsk-ptyadav-1c-43206220.eu-west-1.amazon.com (Postfix, from userid 23027615) id 89B166204; Fri, 16 May 2025 17:28:17 +0200 (CEST) From: Pratyush Yadav To: Mike Rapoport CC: Andrew Morton , Alexander Gordeev , Andreas Larsson , "Andy Lutomirski" , Ard Biesheuvel , "Arnd Bergmann" , Borislav Petkov , Brian Cain , Catalin Marinas , Dave Hansen , "David S. Miller" , "Dinh Nguyen" , Geert Uytterhoeven , Gerald Schaefer , Guo Ren , Heiko Carstens , Helge Deller , "Huacai Chen" , Ingo Molnar , Jiaxun Yang , Johannes Berg , "John Paul Adrian Glaubitz" , Madhavan Srinivasan , Mark Brown , Matt Turner , Max Filippov , Michael Ellerman , Michal Simek , Palmer Dabbelt , Peter Zijlstra , "Richard Weinberger" , Russell King , "Stafford Horne" , Thomas Bogendoerfer , Thomas Gleixner , Vasily Gorbik , Vineet Gupta , Will Deacon , "Praveen Kumar" , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 10/13] arch, mm: set high_memory in free_area_init() In-Reply-To: <20250313135003.836600-11-rppt@kernel.org> References: <20250313135003.836600-1-rppt@kernel.org> <20250313135003.836600-11-rppt@kernel.org> Date: Fri, 16 May 2025 17:28:17 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 86E1C1A000E X-Stat-Signature: c5ccc87z11bhp1wt7ia5yz4nhks8ssmi X-HE-Tag: 1747409307-309184 X-HE-Meta: U2FsdGVkX18NuA50RLrR3zyoEeVvQRmirST3vPhd/4reX1d6tXEywasAWBl9wfQzIYpRq/WK/L488lP3yjjvGqq08Jyq94FZqk2WfpBFesMab/EQiwhrQ0Pn6rK3cNjtbiPfENN6qEr5CY70FElPKN7WSMUOcCjYk8ivIC8vuwC/i36Z1i/RFhKgQcslJN5cVqfL0gW3d5ZY5sdNWPs82V3yN/JNnOkkY0QjdwgDxGrw62gZ9gFFFXAGaZrpRuVAKqISh0g9v1KwSx+jA2svuAia194ZNyXZXPfWKLzvTrGF1mSHx7lpkTfVPhey6dTUeLf2RNfVEDB7c4j+ZYxc6KsDfGAqE62eFtNcPhFo8/rPuk9yu33NPgDra7LmRUDLvXVpgx6nqXssm2jsxhL5+pxLmRK72jx+5bwpHpM4FUK1JTbTyW5ISEJgKIPIM2QKsVabXhgsLIswrUHW6mqXKY3OYISmQ37hlkdURWuHskBr6zzcXZIlKy748X7/nuXYJcRKFbzpwN8GQb/GPXFCY9+dLl0NdK73wYing+zNBbeJ+5eh/mDSOynijuGt47V7AR9l3H073R6Vk/JMFepbxMUY4q1VVYUj+752sr/u44SLYU0igLT9VuIy5Ea2K31Xv/kthkmhE5gjxZRVxJdXavt+spIAVV/aDxS7ZV6xAeZdqVlNVvkVQyIa2MNo26ReE5U2t7jCUnQxFUwOSsL2RR0CNAaFEisk1fGtnuVD1qxNb74XaWgdeHu/2TzQr4IY1dpu/vOzmMvpcAjIMHaFE6EudG+sqF4U58k//Nl/TOXKXnCoFAgF+8f0Gxe8KciMD+c4QZCeOH8UbXKQZ6HBd/4f9wl2qCkcD4pWrtRLGOYYP236PCgJ9mbWVrnfARdpdahQSXkb6NETJEHROFUAZC5SeUUYWvJE2l6V8oElyWJHKgUkWeXz0R2pCXwRHhuZ0lYnRedNpUQKdZrY0mN +es/P3kI DtJ/CHD6zJbLA1r3QIEFJMlUonyu4snsdUQfZXngNjfG1g/Zy7AoBv7Tz0ikpblVy4Z0iytCqaK7X4f4BTWRG6gpWxK9KTRu5jKqzeq65mkQrO1OGfz+ClDtHMSG6IVdWlrzXlnsc+TK2i7cQAj9w0sfZTHHQCCY+/+DGOWJXHvcWkJg35ObAUxlYz2oKnzlPtM06u2lO7sVPRQNT5bS0X1cgSVNF2wbvoeNvcE1hy/B3UZSwY+dZSoSaD50VMrMqDpYCoYZ5Nyq3zaO806BXyB3AEoSR/SoMOrNfix9kXRK/+61kz6T4o/rG0F2sowCLdKcffsRRN90/VnGmWyuC8udC24LFrem7wM7y8xr/RTjNgqyJecBCMI7R3bj6nQD/Jmg3KILVsE5JmNNf1qyUyrYitZQEYamMwzywIM0EeQNRhc8OhQ2rBbeYzbZ9eZdClZ3V 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: Hi Mike, Andrew, On Thu, Mar 13 2025, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > high_memory defines upper bound on the directly mapped memory. > This bound is defined by the beginning of ZONE_HIGHMEM when a system has > high memory and by the end of memory otherwise. > > All this is known to generic memory management initialization code that > can set high_memory while initializing core mm structures. > > Add a generic calculation of high_memory to free_area_init() and remove > per-architecture calculation except for the architectures that set and > use high_memory earlier than that. > > Acked-by: Dave Hansen # x86 > Signed-off-by: Mike Rapoport (Microsoft) > --- > arch/alpha/mm/init.c | 1 - > arch/arc/mm/init.c | 2 -- > arch/arm64/mm/init.c | 2 -- > arch/csky/mm/init.c | 1 - > arch/hexagon/mm/init.c | 6 ------ > arch/loongarch/kernel/numa.c | 1 - > arch/loongarch/mm/init.c | 2 -- > arch/microblaze/mm/init.c | 2 -- > arch/mips/mm/init.c | 2 -- > arch/nios2/mm/init.c | 6 ------ > arch/openrisc/mm/init.c | 2 -- > arch/parisc/mm/init.c | 1 - > arch/riscv/mm/init.c | 1 - > arch/s390/mm/init.c | 2 -- > arch/sh/mm/init.c | 7 ------- > arch/sparc/mm/init_32.c | 1 - > arch/sparc/mm/init_64.c | 2 -- > arch/um/kernel/um_arch.c | 1 - > arch/x86/kernel/setup.c | 2 -- > arch/x86/mm/init_32.c | 3 --- > arch/x86/mm/numa_32.c | 3 --- > arch/xtensa/mm/init.c | 2 -- > mm/memory.c | 8 -------- > mm/mm_init.c | 30 ++++++++++++++++++++++++++++++ > mm/nommu.c | 2 -- > 25 files changed, 30 insertions(+), 62 deletions(-) This patch causes a BUG() when built with CONFIG_DEBUG_VIRTUAL and passing in the cma= commandline parameter: ------------[ cut here ]------------ kernel BUG at arch/x86/mm/physaddr.c:23! ception 0x06 IP 10:ffffffff812ebbf8 error 0 cr2 0xffff88903ffff000 CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc6+ #231 PREEMPT(undef) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:__phys_addr+0x58/0x60 Code: 01 48 89 c2 48 d3 ea 48 85 d2 75 05 e9 91 52 cf 00 0f 0b 48 3d ff ff ff 1f 77 0f 48 8b 05 20 54 55 01 48 01 d0 e9 78 52 cf 00 <0f> 0b 90 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0000:ffffffff82803dd8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000 RAX: 000000007fffffff RBX: 00000000ffffffff RCX: 0000000000000000 RDX: 000000007fffffff RSI: 0000000280000000 RDI: ffffffffffffffff RBP: ffffffff82803e68 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff83153180 R11: ffffffff82803e48 R12: ffffffff83c9aed0 R13: 0000000000000000 R14: 0000001040000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff88903ffff000 CR3: 0000000002838000 CR4: 00000000000000b0 Call Trace: ? __cma_declare_contiguous_nid+0x6e/0x340 ? cma_declare_contiguous_nid+0x33/0x70 ? dma_contiguous_reserve_area+0x2f/0x70 ? setup_arch+0x6f1/0x870 ? start_kernel+0x52/0x4b0 ? x86_64_start_reservations+0x29/0x30 ? x86_64_start_kernel+0x7c/0x80 ? common_startup_64+0x13e/0x141 The reason is that __cma_declare_contiguous_nid() does: highmem_start = __pa(high_memory - 1) + 1; If dma_contiguous_reserve_area() (or any other CMA declaration) is called before free_area_init(), high_memory is uninitialized. Without CONFIG_DEBUG_VIRTUAL, it will likely work but use the wrong value for highmem_start. Among the architectures this patch touches, the below call dma_contiguous_reserve_area() _before_ free_area_init(): - x86 - s390 - mips - riscv - xtensa - loongarch - csky The below call it _after_ free_area_init(): - arm64 And the below don't call it at all: - sparc - nios2 - openrisc - hexagon - sh - um - alpha One possible fix would be to move the calls to dma_contiguous_reserve_area() after free_area_init(). On x86, it would look like the diff below. The obvious downside is that moving the call later increases the chances of allocation failure. I'm not sure how much that actually matters, but at least on x86, that means crash kernel and hugetlb reservations go before DMA reservation. Also, adding a patch like that at rc7 is a bit risky. The other option would be to revert this. I tried a revert, but it isn't trivial. It runs into merge conflicts in pretty much all of the arch files. Maybe reverting patches 11, 12, and 13 as well would make it easier but I didn't try that. Which option should we take? If we want to move dma_contiguous_reserve_area() a bit further down the line then I can send a patch doing that on the rest of the architectures. Otherwise I can try my hand at the revert. --- 8< --- diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 9d2a13b37833..ca6928dde0c9 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1160,7 +1160,6 @@ void __init setup_arch(char **cmdline_p) x86_flattree_get_config(); initmem_init(); - dma_contiguous_reserve(max_pfn_mapped << PAGE_SHIFT); if (boot_cpu_has(X86_FEATURE_GBPAGES)) { hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); @@ -1178,6 +1177,8 @@ void __init setup_arch(char **cmdline_p) x86_init.paging.pagetable_init(); + dma_contiguous_reserve(max_pfn_mapped << PAGE_SHIFT); + kasan_init(); /* -- Regards, Pratyush Yadav Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597