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 D51B5C36018 for ; Wed, 2 Apr 2025 20:19:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC66D280006; Wed, 2 Apr 2025 16:19:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E4E26280003; Wed, 2 Apr 2025 16:19:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D16DC280006; Wed, 2 Apr 2025 16:19:13 -0400 (EDT) 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 B2C1E280003 for ; Wed, 2 Apr 2025 16:19:13 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CF27F120881 for ; Wed, 2 Apr 2025 20:19:13 +0000 (UTC) X-FDA: 83290218186.30.C77E142 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf22.hostedemail.com (Postfix) with ESMTP id EC3F0C0002 for ; Wed, 2 Apr 2025 20:19:11 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TNsGv5RE; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743625152; a=rsa-sha256; cv=none; b=R3a0gq2g/6pUO6jsVL+4mp6BERsC2tJ3NJ/KRSQICGsEu3+374/8eXXYKtCO4W6unn6gYm FVfAEK+LwcgMqzMnaJh8oNFk6HkvO0e4T0OeX9FbcmEsurQk2IzOw/OJrM/+7Q6nPh8ATR vAi35/KOejK+IJV2IAtODIpMVJ51RrY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TNsGv5RE; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743625152; 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=7DoL8LQYkuBpOPrwlge2KAlQGloJse5r2FCqgJYmNFk=; b=EfasxiaGBNv1V9BCj7veupekh6q3hyu7mLSHdFDM+ivh7A3s91f8L8P0JR8C84c0uIjIPD ybNvLUDIVlmctXoGNyax5BgvAz+6i3A+DET+MVk2INeBlYyt6m0rTuSN26IQxMZjmvbodH Sg9+k152BtBkJ48Wpu5fMJyB5vIoERk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 17B8343D9E; Wed, 2 Apr 2025 20:19:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5554BC4CEDD; Wed, 2 Apr 2025 20:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743625150; bh=PBAlCXXoeZYK4hLqIaAvGTjwa5glXZM1tJS6eSjSSww=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TNsGv5REBUv5cCT3Y6XQje0aF3DB0+YmNtT4Z8Guj8UnqP9RDvNkPh30jZCNJ6ym/ ZYe5NowHojMJrVjp7O1ai7s2tjouVNUHS0RUE7OZayzmNTZNGUgq36PRUDhK0aZaFU ujflV2XCHpWTbN2b6vk/r5o9Ttku8oPuqsL8H1j410RsfZ4NlTatOVmbdm4guXXZqp bVKxgqmn5hngT7OjGOvj5fCLkUw0lcHgNdtXqygBbwQaJl+A9AwUNeCv70o9iFpba5 4yoqbCjOIKhAZBP1SyDDZKiTsH2KyjMsLt9ILHAC85utAuq/POgnQVkBFhnZ21G4md h4MoLQ9RrqesQ== Date: Wed, 2 Apr 2025 23:18:55 +0300 From: Mike Rapoport To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= 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: 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> <20250402181842-f25872a1-00f7-4a8f-ae6d-3927899ee3a6@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250402181842-f25872a1-00f7-4a8f-ae6d-3927899ee3a6@linutronix.de> X-Rspamd-Queue-Id: EC3F0C0002 X-Stat-Signature: mhzbix64qwydbtsswk5x7nsxy5d6k3gw X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1743625151-985074 X-HE-Meta: U2FsdGVkX18rJQsGZzA5vAjl35gloitIrnv41o2OoypTNGvWxVMWhIblCCoAVJ7mammiJTW/jREVxypPsY3bn3ppLXqbiD8v6Ax03xHhJ5HKFaS05KBXYdmunJHssnMDKwr16uEChWDLO513oVqOb66BjoaCqNh389QeC8MqfEf/kUFpogdQ8omnZz03nLEoDgBoaixax8AmrT44h5BTFwEbMjR7EGXILwNLVOssju1WtfeuNWSqZFobSwjnjYK/iSvAhcTOoeAB5GFq1+q+xH1tgPBMGwOhO6SZYva1qvjeMFrFCww+Cty9ecdL/q7Q6UyEOL2J4/tMx6iKwMdFwRclmpJmnvYq8i8lxHscinDSWxjMTAfj8BfWAiMM0B0WKIgsnYfcK4hpDS/dYaFNO+7hdDl10JMEJ1wpCVx3VKl5uNRgLX79ECTu4eIIwR3CSwwALURvyronQKz69AdnNkolv0q4EzjBg4MZGB3aYZN3okRLU7hJ9364DsGACVCDXTWf9yjCTzNGA2d0PqLfHTk/DqzPuRCIz/iXkAbNa1OucrJcQ/r+VUbwMsAUOFrqOEYkTASg8No7P90R7AYHPSy+JyvVcX6ldtEtuKmL5LHotrDINYu/nfV7Q9koyl5QJCYL3HyxB8vTirFTZH8SjK+74/ziEsdX/u7TRrhORKm7JgDJLFvroSYf///X6CAhdE/aHSjrF/AkmlYyDh6JBTLew7i+yuHzVNusNSiV8NThoDwJKzpXV1I9nF3T8alH/3Jx4+DIaGDNTzwFhptl8AOwon6nG+E7Q6XmH5HCQfn1+BUdj3BgOpiFb+xa12go7YUfYthdXid6gVb8KJJHcX59GssVCXtBdCIHMjCfJJPmwDoikTgsSiItpP95dku9f+3psTXFQNJsjg4946Vvc79EypLJYjOOuIFxDmOkEH/mpoidU+3q5E3A8qHUGFrphe+6QvWsUs2p3J7u7sU gUiu26Nr I1B/BLHQxYsfzl0yuLAULNXMIzMpKdQa0y5KLyKRCF3iBp4QVGqwMaMCiMRZLIFjNW+hPW92TfXm/92wT5fU6EOEOZTBw8HIorjJ3ruE/KFx7KKpe8YcG1vLm/wcqNRCXtwq6KddX1lKalevh+QZQBR02qygRlhF4V/FfGB7kuhbUvNuRhtB/PwIQN38eccQaL42NHgn86zTNz9Ofz2tVAD10C5vKl4f3c6R5QnGmKCE7bTM5jcJAvQRNysWo6flaiT0y0iabukdLYphAaKfSKbf9YZxIUnUxMgyfo2wlUC2SSgWrc4Ma9BpBH1tGlUcI4m6iCADspWYjmfwlAiGh+5Dq1rlJeE0GSCMUyRNoWiR9sTTsKyr7L/Nepw== 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 06:31:02PM +0200, Thomas Weißschuh wrote: > 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); This will leave HIGHMEM completely unusable. The proper fix is diff --git a/mm/memblock.c b/mm/memblock.c index 64ae678cd1d1..d7ff8dfe5f88 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -2166,6 +2166,9 @@ static unsigned long __init __free_memory_core(phys_addr_t start, unsigned long start_pfn = PFN_UP(start); unsigned long end_pfn = PFN_DOWN(end); + if (!IS_ENABLED(CONFIG_HIGHMEM) && end_pfn > max_low_pfn) + end_pfn = max_low_pfn; + if (start_pfn >= end_pfn) return 0; I've sent it along with the fix for x86 [1] (commit 7790c9c9265e ("memblock: don't release high memory to page allocator when HIGHMEM is off") in mm-unstable), but for some reason it didn't make it to the Linus tree :/ @Andrew, are you going to send it to Linus or you prefer if I take it via memblock tree? [1] https://lore.kernel.org/all/20250325114928.1791109-3-rppt@kernel.org/ > 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 -- Sincerely yours, Mike.