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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 86B33C04FF8 for ; Thu, 18 Apr 2024 12:41:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=her/GCItoVnz7gRj0j5ANnSos69p8ws1CXXmR85cTNM=; b=EP4DsDpIbeeW/T vMZoPCgAVRDoKBB4GRWINvUy7g8+F44eRx8DPG9KvFmArTy3IYCZfOjQ+vBoSI3W4m/GGPIoIzvQb 3/Q0iF9xBoaRlbbnNpmsjYoN5myTdMLgpYr0quApIIyU3Y+dqBU6gpLjxdIWF+RTlzJBHDLt0+HN9 1MdGmaOkNFAPfUojzyhz2Y0O3qslBsjWYXsCQopkbLNVhJTBQ4Y3iKpdUfxdYmq7qPWeWk4OsYyqQ IoalL46CQFy4bkbP2GZbX/GGkD/uN0t8Kt4SFIufT4Sm9/IozpHTiKhfyUPuG5MEPozKgsoSpc452 o9ob9tk9/FBZV9gRfsgw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxR5K-00000002C9I-1Paf; Thu, 18 Apr 2024 12:41:50 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxR5F-00000002C6d-1U1b for linux-riscv@lists.infradead.org; Thu, 18 Apr 2024 12:41:48 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 910C5CE14E7; Thu, 18 Apr 2024 12:41:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F318C113CC; Thu, 18 Apr 2024 12:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713444101; bh=5Gg1cGKKy8xUY1IPDW6LNh+LEVolae4Ho+4aUJeL+nE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BtC7KXLlU2MWKMuknCac4v0q0WkuRC0gLCVBTgCsJvlKLj0Q1BcuZPTIrz/vGSb6t Ya/T3ZkMMJYdY0GVTm0WxUZ0pVNKW9Wu689lsPx7voDaaT1OsHF5xAvu7F/LS27XkG h9bLsT36smOCiRuXbWqlsw2sdS/xPxU75bdG3xfcHp2hP+0m5qWpQuJqksXq+TeS0U Wdwb2T8r/Y8/7EaWiJCU2ESE1WIVb5YWurFDwZ8az/hmSaPmgIRf3HJMRwKJeEl7xr Tq8bH12Zr+B0O1zxoe4UG9dCavvht3yNO8Hm9QQIG/OlHLYJu7UsCv9eNM3ordhePo yVAiYovW2QLhw== From: =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= To: Nam Cao , Mike Rapoport , Andreas Dilger , linux-riscv@lists.infradead.org, Thomas Gleixner , Andrew Morton , "ndesaulniers @ google . com" , Luis Chamberlain , Ingo Molnar , Christophe Leroy , Tejun Heo , Krister Johansen , Changbin Du , Arnd Bergmann , Geert Uytterhoeven , linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Subject: Re: [PATCH] init: fix allocated page overlapping with PTR_ERR In-Reply-To: <20240418131238.636bee2c@namcao> References: <20240418102943.180510-1-namcao@linutronix.de> <20240418131238.636bee2c@namcao> Date: Thu, 18 Apr 2024 14:41:38 +0200 Message-ID: <87edb2sv0d.fsf@all.your.base.are.belong.to.us> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240418_054145_811952_DF50BF44 X-CRM114-Status: GOOD ( 20.61 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org TmFtIENhbyA8bmFtY2FvQGxpbnV0cm9uaXguZGU+IHdyaXRlczoKCj4gT24gMjAyNC0wNC0xOCBO YW0gQ2FvIHdyb3RlOgo+PiBUaGVyZSBpcyBub3RoaW5nIHByZXZlbnRpbmcga2VybmVsIG1lbW9y eSBhbGxvY2F0b3JzIGZyb20gYWxsb2NhdGluZyBhCj4+IHBhZ2UgdGhhdCBvdmVybGFwcyB3aXRo IFBUUl9FUlIoKSwgZXhjZXB0IGZvciBhcmNoaXRlY3R1cmUtc3BlY2lmaWMKPj4gY29kZSB0aGF0 IHNldHVwIG1lbWJsb2NrLgo+PiAKPj4gSXQgd2FzIGRpc2NvdmVyZWQgdGhhdCBSSVNDViBhcmNo aXRlY3R1cmUgZG9lc24ndCBzZXR1cCBtZW1ibG9jawo+PiBjb3JlY3RseSwgbGVhZGluZyB0byBh IHBhZ2Ugb3ZlcmxhcHBpbmcgd2l0aCBQVFJfRVJSKCkgYmVpbmcgYWxsb2NhdGVkLAo+PiBhbmQg c3Vic2VxdWVudGx5IGNyYXNoaW5nIHRoZSBrZXJuZWwgKGxpbmsgaW4gQ2xvc2U6ICkKPj4gCj4+ IFRoZSByZXBvcnRlZCBjcmFzaCBoYXMgbm90aGluZyB0byBkbyB3aXRoIFBUUl9FUlIoKTogdGhl IGxhc3QgcGFnZQo+PiAoYXQgYWRkcmVzcyAweGZmZmZmMDAwKSBiZWluZyBhbGxvY2F0ZWQgbGVh ZHMgdG8gYW4gdW5leHBlY3RlZAo+PiBhcml0aG1ldGljIG92ZXJmbG93IGluIGV4dDQ7IGJ1dCBz dGlsbCwgdGhpcyBwYWdlIHNob3VsZG4ndCBiZQo+PiBhbGxvY2F0ZWQgaW4gdGhlIGZpcnN0IHBs YWNlLgo+PiAKPj4gQmVjYXVzZSBQVFJfRVJSKCkgaXMgYW4gYXJjaGl0ZWN0dXJlLWluZGVwZW5k ZW50IHRoaW5nLCB3ZSBzaG91bGRuJ3QKPj4gYXNrIGV2ZXJ5IHNpbmdsZSBhcmNoaXRlY3R1cmUg dG8gc2V0IHRoaXMgdXAuIFRoZXJlIG1heSBiZSBvdGhlcgo+PiBhcmNoaXRlY3R1cmVzIGJlc2lk ZSBSSVNDViB0aGF0IGhhdmUgdGhlIHNhbWUgcHJvYmxlbS4KPj4gCj4+IEZpeCB0aGlzIG9uZSBh bmQgZm9yIGFsbCBieSByZXNlcnZpbmcgdGhlIHBoeXNpY2FsIG1lbW9yeSBwYWdlIHRoYXQKPj4g bWF5IGJlIG1hcHBlZCB0byB0aGUgbGFzdCB2aXJ0dWFsIG1lbW9yeSBwYWdlIGFzIHBhcnQgb2Yg bG93IG1lbW9yeS4KPj4gCj4+IFVuZm9ydHVuYXRlbHksIHRoaXMgbWVhbnMgaWYgdGhlcmUgaXMg YWN0dWFsIG1lbW9yeSBhdCB0aGlzIHJlc2VydmVkCj4+IGxvY2F0aW9uLCB0aGF0IG1lbW9yeSB3 aWxsIGJlY29tZSBpbmFjY2Vzc2libGUuIEhvd2V2ZXIsIGlmIHRoaXMgcGFnZQo+PiBpcyBub3Qg cmVzZXJ2ZWQsIGl0IGNhbiBvbmx5IGJlIGFjY2Vzc2VkIGFzIGhpZ2ggbWVtb3J5LCBzbyB0aGlz Cj4+IGRvZXNuJ3QgbWF0dGVyIGlmIGhpZ2ggbWVtb3J5IGlzIG5vdCBzdXBwb3J0ZWQuIEV2ZW4g aWYgaGlnaCBtZW1vcnkgaXMKPj4gc3VwcG9ydGVkLCBpdCBpcyBzdGlsbCBvbmx5IG9uZSBwYWdl Lgo+PiAKPj4gQ2xvc2VzOiBodHRwczovL2xvcmUua2VybmVsLm9yZy9saW51eC1yaXNjdi84Nzhy MWlicGRuLmZzZkBhbGwueW91ci5iYXNlLmFyZS5iZWxvbmcudG8udXMKPj4gU2lnbmVkLW9mZi1i eTogTmFtIENhbyA8bmFtY2FvQGxpbnV0cm9uaXguZGU+Cj4+IENjOiA8c3RhYmxlQHZnZXIua2Vy bmVsLm9yZz4gIyBhbGwgdmVyc2lvbnMKPgo+IFNvcnJ5LCBmb3Jnb3QgdG8gYWRkOgo+IFJlcG9y dGVkLWJ5OiBCasO2cm4gVMO2cGVsIDxiam9ybkBrZXJuZWwub3JnPgoKSG1tLCBjYW4ndCB3ZSBn ZXQgcmlkIG9mIHRoZSB3aG9sZSBjaGVjayBpbiBhcmNoL3Jpc2N2L21tL2luaXQuYyBmb3IKMzJi PwoKLS04PC0tCmRpZmYgLS1naXQgYS9hcmNoL3Jpc2N2L21tL2luaXQuYyBiL2FyY2gvcmlzY3Yv bW0vaW5pdC5jCmluZGV4IGZlOGUxNTkzOTRkOC4uMWU5MWQ1NzI4ODg3IDEwMDY0NAotLS0gYS9h cmNoL3Jpc2N2L21tL2luaXQuYworKysgYi9hcmNoL3Jpc2N2L21tL2luaXQuYwpAQCAtMTk2LDcg KzE5Niw2IEBAIGVhcmx5X3BhcmFtKCJtZW0iLCBlYXJseV9tZW0pOwogc3RhdGljIHZvaWQgX19p bml0IHNldHVwX2Jvb3RtZW0odm9pZCkKIHsKIAlwaHlzX2FkZHJfdCB2bWxpbnV4X2VuZCA9IF9f cGFfc3ltYm9sKCZfZW5kKTsKLQlwaHlzX2FkZHJfdCBtYXhfbWFwcGVkX2FkZHI7CiAJcGh5c19h ZGRyX3QgcGh5c19yYW1fZW5kLCB2bWxpbnV4X3N0YXJ0OwogCiAJaWYgKElTX0VOQUJMRUQoQ09O RklHX1hJUF9LRVJORUwpKQpAQCAtMjM0LDIxICsyMzMsNiBAQCBzdGF0aWMgdm9pZCBfX2luaXQg c2V0dXBfYm9vdG1lbSh2b2lkKQogCWlmIChJU19FTkFCTEVEKENPTkZJR182NEJJVCkpCiAJCWtl cm5lbF9tYXAudmFfcGFfb2Zmc2V0ID0gUEFHRV9PRkZTRVQgLSBwaHlzX3JhbV9iYXNlOwogCi0J LyoKLQkgKiBtZW1ibG9jayBhbGxvY2F0b3IgaXMgbm90IGF3YXJlIG9mIHRoZSBmYWN0IHRoYXQg bGFzdCA0SyBieXRlcyBvZgotCSAqIHRoZSBhZGRyZXNzYWJsZSBtZW1vcnkgY2FuIG5vdCBiZSBt YXBwZWQgYmVjYXVzZSBvZiBJU19FUlJfVkFMVUUKLQkgKiBtYWNyby4gTWFrZSBzdXJlIHRoYXQg bGFzdCA0ayBieXRlcyBhcmUgbm90IHVzYWJsZSBieSBtZW1ibG9jawotCSAqIGlmIGVuZCBvZiBk cmFtIGlzIGVxdWFsIHRvIG1heGltdW0gYWRkcmVzc2FibGUgbWVtb3J5LiAgRm9yIDY0LWJpdAot CSAqIGtlcm5lbCwgdGhpcyBwcm9ibGVtIGNhbid0IGhhcHBlbiBoZXJlIGFzIHRoZSBlbmQgb2Yg dGhlIHZpcnR1YWwKLQkgKiBhZGRyZXNzIHNwYWNlIGlzIG9jY3VwaWVkIGJ5IHRoZSBrZXJuZWwg bWFwcGluZyB0aGVuIHRoaXMgY2hlY2sgbXVzdAotCSAqIGJlIGRvbmUgYXMgc29vbiBhcyB0aGUg a2VybmVsIG1hcHBpbmcgYmFzZSBhZGRyZXNzIGlzIGRldGVybWluZWQuCi0JICovCi0JaWYgKCFJ U19FTkFCTEVEKENPTkZJR182NEJJVCkpIHsKLQkJbWF4X21hcHBlZF9hZGRyID0gX19wYSh+KHVs b25nKTApOwotCQlpZiAobWF4X21hcHBlZF9hZGRyID09IChwaHlzX3JhbV9lbmQgLSAxKSkKLQkJ CW1lbWJsb2NrX3NldF9jdXJyZW50X2xpbWl0KG1heF9tYXBwZWRfYWRkciAtIDQwOTYpOwotCX0K LQogCW1pbl9sb3dfcGZuID0gUEZOX1VQKHBoeXNfcmFtX2Jhc2UpOwogCW1heF9sb3dfcGZuID0g bWF4X3BmbiA9IFBGTl9ET1dOKHBoeXNfcmFtX2VuZCk7CiAJaGlnaF9tZW1vcnkgPSAodm9pZCAq KShfX3ZhKFBGTl9QSFlTKG1heF9sb3dfcGZuKSkpOwotLTg8LS0KCk1pa2UgaGludHMgdGhhdCdz ICpub3QqIHRoZSBjYXNlCihodHRwczovL2xvcmUua2VybmVsLm9yZy9saW51eC1yaXNjdi9aaUFr Uk1VZmlQRFVHUGRMQGtlcm5lbC5vcmcvKS4KbWVtYmxvY2tfcmVzZXJ2ZSgpIHNob3VsZCBkaXNh bGxvdyBhbGxvY2F0aW9uIGFzIHdlbGwsIG5vPwoKVGhhbmtzLCBhbmQgRldJVzoKClRlc3RlZC1i eTogQmrDtnJuIFTDtnBlbCA8Ympvcm5Acml2b3NpbmMuY29tPgoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXJpc2N2IG1haWxpbmcgbGlzdAps aW51eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3Jn L21haWxtYW4vbGlzdGluZm8vbGludXgtcmlzY3YK From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30CCE1E4AD; Thu, 18 Apr 2024 12:41:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713444102; cv=none; b=qJvUWt5goFbSCtKFfQbfy1+AnWgmqChWh0w4ayEkn0X7+qsKUYkd+Y43FMawsPUo0doOClQE7kK2saNKk5S+riSSn6NtikNAhIhYl1fnFdRiThdxiDH+6F98fK/GRpfvoERu7y1mwhZFofVajYrAQFS8cRdzqINfuw7joBEPu3c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713444102; c=relaxed/simple; bh=5Gg1cGKKy8xUY1IPDW6LNh+LEVolae4Ho+4aUJeL+nE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=sknevSAibGndXyA/tUPkNGGIjEoM4LhR+bIT6247szwS9KKirAo/CZ234m/21eFJonXNQoP/G0VMMMT6FBv53llBz3p8q+ofX7GErqezYN9fQQZV+orPjkqu500yxtUZwrW5lsWgGrJ9hEdJCgn01KuR5Y6LXzkSGbU60yjrUUI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BtC7KXLl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BtC7KXLl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F318C113CC; Thu, 18 Apr 2024 12:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713444101; bh=5Gg1cGKKy8xUY1IPDW6LNh+LEVolae4Ho+4aUJeL+nE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BtC7KXLlU2MWKMuknCac4v0q0WkuRC0gLCVBTgCsJvlKLj0Q1BcuZPTIrz/vGSb6t Ya/T3ZkMMJYdY0GVTm0WxUZ0pVNKW9Wu689lsPx7voDaaT1OsHF5xAvu7F/LS27XkG h9bLsT36smOCiRuXbWqlsw2sdS/xPxU75bdG3xfcHp2hP+0m5qWpQuJqksXq+TeS0U Wdwb2T8r/Y8/7EaWiJCU2ESE1WIVb5YWurFDwZ8az/hmSaPmgIRf3HJMRwKJeEl7xr Tq8bH12Zr+B0O1zxoe4UG9dCavvht3yNO8Hm9QQIG/OlHLYJu7UsCv9eNM3ordhePo yVAiYovW2QLhw== From: =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= To: Nam Cao , Mike Rapoport , Andreas Dilger , linux-riscv@lists.infradead.org, Thomas Gleixner , Andrew Morton , "ndesaulniers @ google . com" , Luis Chamberlain , Ingo Molnar , Christophe Leroy , Tejun Heo , Krister Johansen , Changbin Du , Arnd Bergmann , Geert Uytterhoeven , linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Subject: Re: [PATCH] init: fix allocated page overlapping with PTR_ERR In-Reply-To: <20240418131238.636bee2c@namcao> References: <20240418102943.180510-1-namcao@linutronix.de> <20240418131238.636bee2c@namcao> Date: Thu, 18 Apr 2024 14:41:38 +0200 Message-ID: <87edb2sv0d.fsf@all.your.base.are.belong.to.us> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Nam Cao writes: > On 2024-04-18 Nam Cao wrote: >> There is nothing preventing kernel memory allocators from allocating a >> page that overlaps with PTR_ERR(), except for architecture-specific >> code that setup memblock. >>=20 >> It was discovered that RISCV architecture doesn't setup memblock >> corectly, leading to a page overlapping with PTR_ERR() being allocated, >> and subsequently crashing the kernel (link in Close: ) >>=20 >> The reported crash has nothing to do with PTR_ERR(): the last page >> (at address 0xfffff000) being allocated leads to an unexpected >> arithmetic overflow in ext4; but still, this page shouldn't be >> allocated in the first place. >>=20 >> Because PTR_ERR() is an architecture-independent thing, we shouldn't >> ask every single architecture to set this up. There may be other >> architectures beside RISCV that have the same problem. >>=20 >> Fix this one and for all by reserving the physical memory page that >> may be mapped to the last virtual memory page as part of low memory. >>=20 >> Unfortunately, this means if there is actual memory at this reserved >> location, that memory will become inaccessible. However, if this page >> is not reserved, it can only be accessed as high memory, so this >> doesn't matter if high memory is not supported. Even if high memory is >> supported, it is still only one page. >>=20 >> Closes: https://lore.kernel.org/linux-riscv/878r1ibpdn.fsf@all.your.base= .are.belong.to.us >> Signed-off-by: Nam Cao >> Cc: # all versions > > Sorry, forgot to add: > Reported-by: Bj=C3=B6rn T=C3=B6pel Hmm, can't we get rid of the whole check in arch/riscv/mm/init.c for 32b? --8<-- diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index fe8e159394d8..1e91d5728887 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -196,7 +196,6 @@ early_param("mem", early_mem); static void __init setup_bootmem(void) { phys_addr_t vmlinux_end =3D __pa_symbol(&_end); - phys_addr_t max_mapped_addr; phys_addr_t phys_ram_end, vmlinux_start; =20 if (IS_ENABLED(CONFIG_XIP_KERNEL)) @@ -234,21 +233,6 @@ static void __init setup_bootmem(void) if (IS_ENABLED(CONFIG_64BIT)) kernel_map.va_pa_offset =3D PAGE_OFFSET - phys_ram_base; =20 - /* - * memblock allocator is not aware of the fact that last 4K bytes of - * the addressable memory can not be mapped because of IS_ERR_VALUE - * macro. Make sure that last 4k bytes are not usable by memblock - * if end of dram is equal to maximum addressable memory. For 64-bit - * kernel, this problem can't happen here as the end of the virtual - * address space is occupied by the kernel mapping then this check must - * be done as soon as the kernel mapping base address is determined. - */ - if (!IS_ENABLED(CONFIG_64BIT)) { - max_mapped_addr =3D __pa(~(ulong)0); - if (max_mapped_addr =3D=3D (phys_ram_end - 1)) - memblock_set_current_limit(max_mapped_addr - 4096); - } - min_low_pfn =3D PFN_UP(phys_ram_base); max_low_pfn =3D max_pfn =3D PFN_DOWN(phys_ram_end); high_memory =3D (void *)(__va(PFN_PHYS(max_low_pfn))); --8<-- Mike hints that's *not* the case (https://lore.kernel.org/linux-riscv/ZiAkRMUfiPDUGPdL@kernel.org/). memblock_reserve() should disallow allocation as well, no? Thanks, and FWIW: Tested-by: Bj=C3=B6rn T=C3=B6pel