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 6FF86C28B20 for ; Wed, 2 Apr 2025 16:31:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49409280003; Wed, 2 Apr 2025 12:31:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 41AAA280001; Wed, 2 Apr 2025 12:31:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29275280003; Wed, 2 Apr 2025 12:31:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 068F7280001 for ; Wed, 2 Apr 2025 12:31:09 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F39501401C9 for ; Wed, 2 Apr 2025 16:31:09 +0000 (UTC) X-FDA: 83289643458.30.B51C7F9 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf13.hostedemail.com (Postfix) with ESMTP id 0869320003 for ; Wed, 2 Apr 2025 16:31:07 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=aPXkPsRI; dkim=pass header.d=linutronix.de header.s=2020e header.b=n1+9FCz0; spf=pass (imf13.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743611468; 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:dkim-signature; bh=xd1KphlzMCu4Z6pJqyX+aES04YRk8Sgi26znrqcmoIg=; b=pEXP5sR6FhI0FSj3YRcViQYkPk61XF4MaDedFT/CfvQHK0xlt9jVeevGWqvKwrifD7Cu4G EQ7iVRzLT8ASVM1WO5yraQ3bWiY5yI1YJwis+4hmpGwfqmQUN8EltNl+3L18Hnc8QFFdiT Ryw8uKsyurSb93KvyTVzlH0GUhpk2xQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=aPXkPsRI; dkim=pass header.d=linutronix.de header.s=2020e header.b=n1+9FCz0; spf=pass (imf13.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743611468; a=rsa-sha256; cv=none; b=e4ZQ4uMHaAfQ7zsVF79acbDUBuzkZy9DSzfQYwgVvkTbfXd3PWgiFh3n6637QYAn8SLGlJ ocoui5Sqzrj4o7s9ecIU0aRCxOxtfgLrgyH9O7BuQBtj7XhUUgp76JuTt7ySG0aENzZa1i et9KIXYcsFutMcegrEkbJy7bnaa6BFQ= Date: Wed, 2 Apr 2025 18:31:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1743611465; h=from:from: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=xd1KphlzMCu4Z6pJqyX+aES04YRk8Sgi26znrqcmoIg=; b=aPXkPsRIIO+gk78hNS3UHwVMimopyiRa1u6YCD+0iGOR+lmT6lbaVwOH99yWvYa+WfQxLF R51hhQM1N/mhrjLz/aLU294Ce1HMRoGVWJKB5LOhsUdIG99UC9WDsVeWAIut8jOTx9xmSN B/i45j3A8a5oIiufsZmj0blDls862jXMfTo+QTqmTCW46OyN7r7mqq59x0oy47iXZ6ca+Y oi6Qyr74IKAKJRGksrokIKJF9UD/s2DTABua+W1VDFbT2QfV+Y3kk3DMx8Z8XdesvqZnbY 4NNnBO9/MVZEK17byNSQ8r6etoNTI0sBKV8HP/1OnYvuoWhWWDF35lq6mzFCCg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1743611465; h=from:from: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=xd1KphlzMCu4Z6pJqyX+aES04YRk8Sgi26znrqcmoIg=; b=n1+9FCz093xgYuvsHQefw2o4N3FjHh4l9TGgA+vPheErSpZmihg0SZ5/I3Og9Dp0GRR6ox +qrb7WjeznoHtOAQ== From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Mike Rapoport Cc: Andrew Morton , Dave Hansen , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , "David S. Miller" , Geert Uytterhoeven , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, Naresh Kamboju , lkft-triage@lists.linaro.org, Linux Regressions Subject: Re: [PATCH v2 10/13] arch, mm: set high_memory in free_area_init() Message-ID: <20250402181842-f25872a1-00f7-4a8f-ae6d-3927899ee3a6@linutronix.de> References: <20250313135003.836600-1-rppt@kernel.org> <20250313135003.836600-11-rppt@kernel.org> <20250402140521-bf9b3743-094e-4097-a189-10cdf1db9255@linutronix.de> <20250402145330-3ff21a6b-fb03-4bc8-8178-51a535582c6f@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250402145330-3ff21a6b-fb03-4bc8-8178-51a535582c6f@linutronix.de> X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0869320003 X-Stat-Signature: 4qk1f7s5er1qiwb6w794cupnkjbbbhnt X-HE-Tag: 1743611467-146280 X-HE-Meta: U2FsdGVkX1/WGRri4+WlYWzRUZN2RNH+Aw1oEgC0rOdy5mEb8rTAic8RZ6BQ3PF8neJRLG/pk1geDbNWssZHn6bjXUwcRrZ/3Jm7uAwpLIuIWZmBJSWsasdCC9gW3MvmerpceBoLQlNdRXkZf3fw299/fxoGHx9MUPKr8pOmpZZ6FNApjBI4AdeaWGdMCM01bVPj2xajiv7c/m16xz9MKi2hZb0iS2Fwo2wnemt5Bqd5mn4f+S8FP1uVzWQ0qrU2czIm6VZhF5Ke+oiVOa7C5Oh+TaCv7JVlbJJM72WFz8Fz8+XL275IWra6e6TKAcog1PJexEjxLLheGwbhZu/keEj+hxOj4JJ02bJVfRdI9onWAix1Rh4TDGRjpvd2VjeKgOsQ6BJgtoonQwUMe5MHsbwa8VwM1rnx5jWacBt+VHEq/+g1FBWJMniJN6TNZwIM5yW3QbeyZhNbYNgwbcvgkouCfLJTSLzxBRrpSrDwHqTinakMp+reF2ctgnzVEVDl5EJ9inQjWQGE+af22JKYOe0zfOT8vba3+uqazvRX5HseJLZ/ebU2txKUk1jt+XOOH+FivaUtAYkudXVTsSBpFugEKzNPybixbqSX77T3B95uBabQN+qG9vjLgTHnfvaj1jqKXvkEWDcU0Ph/qhAerdIoWbC2216OU2a7HZzOPw6mafcalf5OTfxDN00bt80yn0SHdvmjMi70fuk8Juiqt0hbSMRnm/yTvGEiM+wBEZ3FSvH3gQUJVyi/jvBMr/gWhjwGCUrhLWEL1GnocPmUIZqCMpdPEM1+vsWbnlLCY+vy0RRmOR0H4GpHgOeV66N46M9qDva/8APZ1TkBosFugXpZ1u3gb9Y4clV+i7gzZzpvezTQgNvQ0deYipyy+Ca9x7IaTG6451KmrsynVHLUOQFmAkaPe9FG/QkWQEzcWfrz93cPzYDY9ByhZU5gSZ7PW3fXyejDSZdHyKotfSa RtUKN6xu Vu2VdI74MhQckztY60YnEtzk7JzS4PoERgaPNEtok3Hom0lY5lyw0l3Qwe+5PL7Cno8bkJ8RROZH/2EbfTFZmlL/Oi6E2yfGfy2B0Veg2ABJOP7dDsF2EbCdJcNrpSZUpvkR2gf0kuA5dcqOSlkP+F1+ms7bPK4aUeu06Kv0RZnnxrSc0jSdkS3IAt6EtIRkdwjCSISSJ2NiGZ6KkY8B7u0gAgIfk/NfxDRGgMfxjRzd64IHqbIw4Ry9WDVtnsT0OtdoY17PmBNObvH5BTPno5T/wOkzsSaQorBRrMxPIF4tGd+iISvvH2xnZZqCjozJHX5so2ebfsCuGvFWa19Env9CXJEKj/+pSGrchyvtQEgpM1gjL8hblKJ68oqrsxojU1al/01mjk48oo2bgBNiJ8sYgq+QdDJF8yGLaQE+D/3ZBFGkWZ3mt9uf9QTQmX7zQWo5RglNnGwJT1x/6h9i/iPeG2jQoYygYgXgKujbEnCHim0jynzUVptewXBJKguX5EixE6Qk7qZyREqkBV5ABA5ky6g== 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 Wed, Apr 02, 2025 at 03:07:51PM +0200, Thomas Weißschuh wrote: > On Wed, Apr 02, 2025 at 03:46:37PM +0300, Mike Rapoport wrote: > > On Wed, Apr 02, 2025 at 02:19:01PM +0200, Thomas Weißschuh wrote: > > > (drop all the non-x86 and non-mm recipients) > > > > > > On Thu, Mar 13, 2025 at 03:50:00PM +0200, 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. > > > > > > This change (in mainline as commit e120d1bc12da ("arch, mm: set high_memory in free_area_init()") > > > breaks booting i386 on QEMU for me (and others [0]). > > > The boot just hangs without output. > > > > > > It's easily reproducible with kunit: > > > ./tools/testing/kunit/kunit.py run --arch i386 > > > > > > See below for the specific problematic hunk. > > > > > > [0] https://lore.kernel.org/lkml/CA+G9fYtdXHVuirs3v6at3UoKNH5keuq0tpcvpz0tJFT4toLG4g@mail.gmail.com/ > > > > > > > > > > diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c > > > > index 6d2f8cb9451e..801b659ead0c 100644 > > > > --- a/arch/x86/mm/init_32.c > > > > +++ b/arch/x86/mm/init_32.c > > > > @@ -643,9 +643,6 @@ void __init initmem_init(void) > > > > highstart_pfn = max_low_pfn; > > > > printk(KERN_NOTICE "%ldMB HIGHMEM available.\n", > > > > pages_to_mb(highend_pfn - highstart_pfn)); > > > > - high_memory = (void *) __va(highstart_pfn * PAGE_SIZE - 1) + 1; > > > > -#else > > > > - high_memory = (void *) __va(max_low_pfn * PAGE_SIZE - 1) + 1; > > > > #endif > > > > > > Reverting this hunk fixes the issue for me. > > > > This is already done by d893aca973c3 ("x86/mm: restore early initialization > > of high_memory for 32-bits"). > > Thanks. Of course I only noticed this shortly after sending my mail. > But this usecase is indeed broken on mainline. > Some further bisecting lead to the mm merge commit being broken, while both its > parents work. That lead the bisection astray. > eb0ece16027f ("Merge tag 'mm-stable-2025-03-30-16-52' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm") > > As unlikely as it sounds, it's reproducible. I'll investigate a bit. The issue is fixed with the following diff: diff --git a/mm/memblock.c b/mm/memblock.c index 284154445409..8cd95f60015d 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -2165,7 +2165,8 @@ static unsigned long __init __free_memory_core(phys_addr_t start, phys_addr_t end) { unsigned long start_pfn = PFN_UP(start); - unsigned long end_pfn = PFN_DOWN(end); + unsigned long end_pfn = min_t(unsigned long, + PFN_DOWN(end), max_low_pfn); if (start_pfn >= end_pfn) return 0; Background: This reverts part of commit 6faea3422e3b ("arch, mm: streamline HIGHMEM freeing") which is the direct child of the partially reverted commit e120d1bc12da ("arch, mm: set high_memory in free_area_init()"). The assumptions the former commit became invalid with the partial revert the latter. This bug only triggers when CONFIG_HIGHMEM=n. When mm was branched from mainline the i386 configuration generated by kunit ended up with CONFIG_HIGHMEM=y. With some recent changes in mainline the kunit configuration switched to CONFIG_HIGHMEM=n, triggering this specific reproducer only when mm got merged into mainline again. New kunit reproducer: ./tools/testing/kunit/kunit.py run --arch i386 example --timeout 10 --kconfig_add CONFIG_HIGHMEM=n Does this sound reasonable? If so I'll send a patch tomorrow. @Naresh, could you test this, too? Thomas