From nobody Tue Dec 16 09:14:24 2025 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 762741E9B2F for ; Mon, 21 Apr 2025 18:52:52 +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=1745261572; cv=none; b=oKIj8zuLV3/jS+RuBgO8xWTuvZZ3wyWPdOLLU/fC/2VC3R8t3JO1A01K8b6Ze6WzKczi7d4NBHKge6IREXL2B1cQoRa14tnJNs+C97rvlDCrhpA1q+4y9GIQshx7duaoWgzA2B0+1TgFoDR4z1kQjyzd/Q4BSzOtPu0Am3kPnmw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261572; c=relaxed/simple; bh=uDJaQQAXGZBIkVwCOP86cyQW8juas8BcKLCPtMEbZhw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=koXUmAwEkx2SRi2QlrKY3FEmy8fXq60y39fOu/SgtheeKUFGcXNcvl+BybAxt98A6uJZTWtjYHUt4zv+uH15EQ7qEz6N10SePjIEqzHj7UaElItU5DQVWQEjmG/XoXkFPjrs3cEOdkYOV68wVYQ0+6cZ0qhLpQ6fyW5G2AbJ2GI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=b1QU7zQ9; 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="b1QU7zQ9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA101C4CEEA; Mon, 21 Apr 2025 18:52:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261572; bh=uDJaQQAXGZBIkVwCOP86cyQW8juas8BcKLCPtMEbZhw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=b1QU7zQ9ULkFoMJr5s1y9so7lT0iYsTHdcX1LBiZ1AdQ4+eUk0I9btU/QwJJ/R2DE riFx1uZCPa/rDD2SnlEeSIWryjfzMixKRDgVIQu61oXSSEdJxPCPOtrvtVIStUWdeO Jo89yspi0OggXU2R6diFacWStXz1ldRu+gMzxKt/3BGoURs0e2Wc0jQVJj2IM+ILpc 6QQmZLYftNU5fGXYlwtItXJH4q7G0hIg5LP/H4Z9OEaydCiFh009pRCqXYNmw4mIIX eiXTkJ21Yvl8SoNJo9BcuHA6++2jSNt7kByHY/qEGi313q3C2zhZbO1m5tPaalcgoa DmwVxP8krhOww== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 01/29] x86/boot/e820: Remove inverted boolean logic from the e820_nomerge() function name, rename it to e820_type_mergeable() Date: Mon, 21 Apr 2025 20:51:41 +0200 Message-ID: <20250421185210.3372306-2-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" It's a bad practice to put inverted logic into function names, flip it back and rename it to e820_type_mergeable(). Add/update a few comments about this function while at it. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 9d8dd8deb2a7..4a81f9e94137 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -304,18 +304,22 @@ static int __init cpcompare(const void *a, const void= *b) return (ap->addr !=3D ap->entry->addr) - (bp->addr !=3D bp->entry->addr); } =20 -static bool e820_nomerge(enum e820_type type) +/* + * Can two consecutive E820 entries of this same E820 type be merged? + */ +static bool e820_type_mergeable(enum e820_type type) { /* * These types may indicate distinct platform ranges aligned to - * numa node, protection domain, performance domain, or other + * NUMA node, protection domain, performance domain, or other * boundaries. Do not merge them. */ if (type =3D=3D E820_TYPE_PRAM) - return true; + return false; if (type =3D=3D E820_TYPE_SOFT_RESERVED) - return true; - return false; + return false; + + return true; } =20 int __init e820__update_table(struct e820_table *table) @@ -393,7 +397,7 @@ int __init e820__update_table(struct e820_table *table) } =20 /* Continue building up new map based on this information: */ - if (current_type !=3D last_type || e820_nomerge(current_type)) { + if (current_type !=3D last_type || !e820_type_mergeable(current_type)) { if (last_type) { new_entries[new_nr_entries].size =3D change_point[chg_idx]->addr - las= t_addr; /* Move forward only if the new size was non-zero: */ --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 A7D401EB197 for ; Mon, 21 Apr 2025 18:52:55 +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=1745261575; cv=none; b=jdOv0Nn06tPDccFLOZLw9FIDUlgTsCOXR7Ej6jc+wMWbXTwgOHNcHlqMdYtXGEEK0dmE+KeeMjpfwZYMsMrXNZ2qAYARXIPn5chjqmbBDyD2HhfnDXKmV7X/v6NEFRor6WaKxvscv+486Fb8dU9Id0+HHvstigG4Wxz3ZMc/q6g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261575; c=relaxed/simple; bh=3Oy+Xg5BKgF+D8WcFy2vULMkJbA8RYiQNkOgq9/P6sY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aYMyiD6rwzw0Mx4FA2WfYwx54K4MjBi1X2PJzHlzZ4WlQT5R1ZHc0ALrU7a0MBK6ukS3566WWaFMQ5Q7S9MSXHM476cqxtJZOZQdOYR4QwT0pXU1u+O1DQU4M5JvDpsCkEIxyNfPlmN6jchvO9IFTRpJrRuoADi+AHH6qoqqto0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ARjfHlyg; 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="ARjfHlyg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE902C4CEF4; Mon, 21 Apr 2025 18:52:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261575; bh=3Oy+Xg5BKgF+D8WcFy2vULMkJbA8RYiQNkOgq9/P6sY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ARjfHlygYBsc3vPdtEEqjq8hIVhRD1Gz7idNum8B4GK6nP6Fy5I++b1710Oq3ZowA /1WTVijB0+MeUSFlv4lcgqkkBz3URxVH0BFo4bgronyu1qXca/5uhbI4EURrCBftON oW9BOC+0Aq44TVdescXdM8ffB3s1rMPicBTPEwqZSmf8EhvEVneto2xDFv1XAT2Uyt v/Khwthj0ckzF5vunC8knEF+NGe3fCrHVj1MqL9/Y5cY3GiAbxtnVb1dJ50KN8PvwR z31MouJxS9233LG+JJxhDRM2q1KSndOsqqCTDSmmC3NI3BN32QrKtDV/dorS/Bm2dw 8LdJ8zV47nkTw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 02/29] x86/boot/e820: Simplify e820__print_table() a bit Date: Mon, 21 Apr 2025 20:51:42 +0200 Message-ID: <20250421185210.3372306-3-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Introduce 'entry' for the current table entry and shorten repetitious use of e820_table->entries[i]. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 4a81f9e94137..b1a30bca56cd 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -204,12 +204,14 @@ void __init e820__print_table(char *who) int i; =20 for (i =3D 0; i < e820_table->nr_entries; i++) { + struct e820_entry *entry =3D e820_table->entries + i; + pr_info("%s: [mem %#018Lx-%#018Lx] ", who, - e820_table->entries[i].addr, - e820_table->entries[i].addr + e820_table->entries[i].size - 1); + entry->addr, + entry->addr + entry->size-1); =20 - e820_print_type(e820_table->entries[i].type); + e820_print_type(entry->type); pr_cont("\n"); } } --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 1A8FE1EDA2E for ; Mon, 21 Apr 2025 18:52:58 +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=1745261578; cv=none; b=MpeU+owbh+GCEhBDtSdw2sDp+1bE4mP+j6yv4+ls6+73m5J641js4kVxFH8j7XoPyuWDs1s2nWdcGjth74W8UyXkpSVJWpkqTBW0T+D//37Qg+Z+vZv4LLQRKssKgrEuQti/TyqV035OyxuY000aIkAQ14q60XRZM4UVvjMlPL4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261578; c=relaxed/simple; bh=V1tQ53oGu5CeA4qMawnkPiBjIoOaEGEvKZ2zIm2OxYk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=e7CCeJkttEveEHag+Fh7rS1hZXTOc2tBzOPdktumEW/b2zoPbKq1+LA4gKvWpiUUQ9pcVGFXCwVP4ABO+Z9wyT8I6pNMddkR2yzZxk+cbTCDT8zp+aNXyjvCxvgul6v8HAYu4wCKgiQGEo1sQj63F58/ZEQnNowOLdJRx/PqHoM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WSAkxbjU; 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="WSAkxbjU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 813BEC4CEE4; Mon, 21 Apr 2025 18:52:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261577; bh=V1tQ53oGu5CeA4qMawnkPiBjIoOaEGEvKZ2zIm2OxYk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WSAkxbjUSDUaZB+cf5fRtZlwOcX6ZqRunt2wvmm+DZ7jMmoIR7t5eS1QdWp5pL6DT GHFJ4hCYT9eC/O8AjSSSZdWlKoXyUbMgc+XlaUpystGSTgcpjhrhoTTMwxMv9143hK IFwnrbWShoRDoNcNIfgxeUFTMqjl3y/FmI30bSrx55p6BsEc1xN9Olkd/2F3ErskPP 9ye7DyTP++xba6oeu/vTudB1jawcD6S9YOTo36xEhlrYfVTIh1GCbZ3XQM35g58nN3 MqwYI7Eg5chHegGbwYobWzMD62p8Gn65gvyCFCmC/VXzhnguzSRdIrJ6BfGM/8RQnc 09su2lKqjyP2w== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 03/29] x86/boot/e820: Simplify the PPro Erratum #50 workaround Date: Mon, 21 Apr 2025 20:51:43 +0200 Message-ID: <20250421185210.3372306-4-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" No need to print out the table - users won't really be able to tell much from it anyway and the messages around this erratum are unnecessarily obtuse. Instead clearly inform the user that a 256 kB hole is being punched in their memory map at the 1.75 GB physical address. Not that there are many PPro users left. :-) Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/setup.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 9d2a13b37833..83cc265140c0 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -988,11 +988,9 @@ void __init setup_arch(char **cmdline_p) trim_bios_range(); #ifdef CONFIG_X86_32 if (ppro_with_ram_bug()) { - e820__range_update(0x70000000ULL, 0x40000ULL, E820_TYPE_RAM, - E820_TYPE_RESERVED); + pr_info("Applying PPro RAM bug workaround: punching 256 kB hole at 1.75 = GB physical.\n"); + e820__range_update(0x70000000ULL, 0x40000ULL, E820_TYPE_RAM, E820_TYPE_R= ESERVED); e820__update_table(e820_table); - printk(KERN_INFO "fixed physical RAM map:\n"); - e820__print_table("bad_ppro"); } #else early_gart_iommu_check(); --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 463AC1EDA2E for ; Mon, 21 Apr 2025 18:53:00 +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=1745261581; cv=none; b=GxELh1QIhx+PFFl99fU2wuL+xf1f0wz9nLYhHQ0aw2fEkPjL9Oc3tFt0H2IW+Acd2x0mYvOq066tSexX6MwUq5aA3Dyzhlq9f/VNQ1ZvpQl1H5lhDC802/S/S8VB90HERhb+8houT+fWDRG/SDv5Uxp76VH4BbrzUNm0bg1bj2c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261581; c=relaxed/simple; bh=q+soH/bpaCN4JUzwBw1Mkp8BHHdljs6ht02P+bNLL1k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JXFKMUb7ypbdCEe3mh/Hkt93nKiTDLqbmvy5cfYg3eLd7LsuVenx5Ikt7WxfGRWgrPOx0CT+NJq/xjm/ogw+ZIBzWuc414bM+dzyE+P91szDak4AfwewhUy2a4PyDnEb0J1aACTyq5aD+DzicqeZFIfbnS9LcCCU+ojFS9gsjPg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nGFRPans; 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="nGFRPans" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54391C4CEEB; Mon, 21 Apr 2025 18:52:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261580; bh=q+soH/bpaCN4JUzwBw1Mkp8BHHdljs6ht02P+bNLL1k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nGFRPansVRtRL48staVCN2BA1d6N5jLKpP4uD2Jb+h4medbE/UiJuxkZ4nXFczAt0 UgjTlyyu0e24VcHvYasorJCMFX2faCTx+6CMHwFM31t+UqU8yP0Uf8aLmiSA9O98Ld Bj3BX2Xf4hx/8u7kJnMC3B4ek2jeDwPyHzuUlduMAMv1szH2/XitRAsRvxhyEMYFGm cCQh5B4FxAI7onl1PRWiFTkFGGAOnoih2RnYonwfNaiGWWrLpI5sGO6h43XTab1IME wFa56sFTWNz/XxptV06SnvCnI/AqVz4rk71TJ5NVkpCIzuFzgC7dd4vnC6CNCLHpCU qtM/6gAgv5EiQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 04/29] x86/boot/e820: Mark e820__print_table() static Date: Mon, 21 Apr 2025 20:51:44 +0200 Message-ID: <20250421185210.3372306-5-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" There are no external users of this function left. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/include/asm/e820/api.h | 1 - arch/x86/kernel/e820.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/ap= i.h index c83645d5b2a8..54427b77bc19 100644 --- a/arch/x86/include/asm/e820/api.h +++ b/arch/x86/include/asm/e820/api.h @@ -19,7 +19,6 @@ extern u64 e820__range_update(u64 start, u64 size, enum = e820_type old_type, enu extern u64 e820__range_remove(u64 start, u64 size, enum e820_type old_typ= e, bool check_type); extern u64 e820__range_update_table(struct e820_table *t, u64 start, u64 = size, enum e820_type old_type, enum e820_type new_type); =20 -extern void e820__print_table(char *who); extern int e820__update_table(struct e820_table *table); extern void e820__update_table_print(void); =20 diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index b1a30bca56cd..4244b6d53fd0 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -199,7 +199,7 @@ static void __init e820_print_type(enum e820_type type) } } =20 -void __init e820__print_table(char *who) +static void __init e820__print_table(const char *who) { int i; =20 --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 2BE4F1EEA3B for ; Mon, 21 Apr 2025 18:53:03 +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=1745261584; cv=none; b=g0/pvmK4C0OaCvd7WnbwwphWMCST2HyU7v28nEcsB5gx6dorD2n8IktBNWGh3mdOEaR71Jin1x6iovIHZDDq7KXYlSSla6oFV62KW/Yz/J5rXqkNEnv5iSrLpSPme8cF+iv93TUgYxE0Tppw6stNACeQRcavBwRqzIBlMwgAPZo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261584; c=relaxed/simple; bh=LP2D+HLFeAICx5kFnVqbT4i5U0kN48Tpqo6HL2ellsQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Hhg5vdmC+LGBMPTAm+KW494W2fZV9H3+uys5n1SXSwM1zfGZ+ABSes3Fq6g1qFYNSKIqF7vJLvD4A5ctqKo7n3Ps7Vmy+3rgKYhVHojRwBOgI0+U5NDQ93lQ1v/G+XYpugdpoejPRQ4kstkk8uXdyRaUkDDUOSEGGK1W8cC3ALI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o/UWrYX8; 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="o/UWrYX8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28487C4CEE4; Mon, 21 Apr 2025 18:53:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261583; bh=LP2D+HLFeAICx5kFnVqbT4i5U0kN48Tpqo6HL2ellsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o/UWrYX8O5Tw00G+NW3i3tWs3FBC6kDp3eSdUyqV/Oe0NG2r6gzCJYJwzVNR7VBOT l5A1ZLJzxgCqo0f8xuEbrDBjJgU7dFNbAlM5qhXzz1u+OeJNGGeVhg16GJWEoQ+eES d3GcmRbD3awrHRiqUqxyOAJv5haj9EVAoSWITh2Ngv3MLEWr3MJO/VCPArOl2oqczq YxPicD1PWTKbPs/2OsdiA7lEDZx2ospqR26Kmhy1t43ogkS7a2v8LZc7fnG0aA2VU3 c2GNklfG8SDdQBKpHLjFRmLh8VNrMtiqHHNon+K/AYhjb0kQ02G/Bd5loDqQxTvzB0 r5f4/0/1uFYIg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 05/29] x86/boot/e820: Print gaps in the E820 table Date: Mon, 21 Apr 2025 20:51:45 +0200 Message-ID: <20250421185210.3372306-6-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Gaps in the E820 table are not obvious at a glance and can easily be overlooked. Print out gaps in the E820 table: Before: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved After: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved BIOS-e820: [gap 0x00000000000a0000-0x00000000000effff] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved BIOS-e820: [gap 0x0000000080000000-0x00000000afffffff] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved BIOS-e820: [gap 0x00000000c0000000-0x00000000fed1bfff] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved BIOS-e820: [gap 0x00000000fed20000-0x00000000feffbfff] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved BIOS-e820: [gap 0x00000000ff000000-0x00000000fffbffff] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved BIOS-e820: [gap 0x0000000100000000-0x000000fcffffffff] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved Also warn about badly ordered E820 table entries: BUG: out of order E820 entry! ( this is printed before the entry is printed, so there's no need to print any additional data with the warning. ) Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 4244b6d53fd0..a8edfa375fbd 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -201,18 +201,32 @@ static void __init e820_print_type(enum e820_type typ= e) =20 static void __init e820__print_table(const char *who) { + u64 range_end_prev =3D 0; int i; =20 for (i =3D 0; i < e820_table->nr_entries; i++) { struct e820_entry *entry =3D e820_table->entries + i; + u64 range_start, range_end; =20 - pr_info("%s: [mem %#018Lx-%#018Lx] ", - who, - entry->addr, - entry->addr + entry->size-1); + range_start =3D entry->addr; + range_end =3D entry->addr + entry->size; =20 + /* Out of order E820 maps should not happen: */ + if (range_start < range_end_prev) + pr_info("BUG: out of order E820 entry!\n"); + + if (range_start > range_end_prev) { + pr_info("%s: [gap %#018Lx-%#018Lx]\n", + who, + range_end_prev, + range_start-1); + } + + pr_info("%s: [mem %#018Lx-%#018Lx] ", who, range_start, range_end-1); e820_print_type(entry->type); pr_cont("\n"); + + range_end_prev =3D range_end; } } =20 --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 EEA231EF090 for ; Mon, 21 Apr 2025 18:53:06 +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=1745261587; cv=none; b=nT6wQJNFlqqR8isk6QlWe99pV8fo1JVFaIM5Vz/ypWiEWLm5/W/ZrJkzaN/95+Y65jlXWOWF0O0tNY7a+7IIy/IjkeSB4cDqxmkdqDxfZ0mBz/Tx5CZ1mcLO9fFQHnxYAr8pVLQzLEd8q1l6vrnutm4lfwsNDqtpMYHXuwtUUNA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261587; c=relaxed/simple; bh=/oChyhJXj9qTCsKml/iiupq76etcChjDOXm8WSw66hU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dMlwJjXgsqcbgZy3q5Bh8513HDMHuSqe+gDvFsGIDhf0JPEaDv4ZjXWzlqKs0/PKEgiCF27HtpRoeOg2YY9A0oagt2inVCIlPgMR2zxk0qGx3k16oyB5FRx5hVHW4mr+nmbbRNoIZ8N5Ca0B090UOdEjYr0dlbtiiqQj+ZLRCzM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TPEvzuVJ; 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="TPEvzuVJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0089CC4CEEF; Mon, 21 Apr 2025 18:53:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261586; bh=/oChyhJXj9qTCsKml/iiupq76etcChjDOXm8WSw66hU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TPEvzuVJqXEUFuM5KP3zXL/pxchgZdxWY5Cxe/uN4fSM+lB7qE4iFIdt5u3O2UZl5 1p6z55aHrOm/3ZQ6QyAzRtgCgIf+jaMCcTH5xjnBMTm8oOzypdvY0FEyEaPtiNVW4P qnN4ozp+K0KCi2K4wSVwCdHoHVceFUamDZzXXNGWHhu667Q9QIBQzEnOGdIYkFPSxq 3QLMs5EpmXBVVAgge0YfhiUvbABykDuXBSqVe4oT1UfRXhRY1BJ6tpN7+NDNnhSShu OWZOMWfXT3JRGVah+VMyFKAeAfSR1JjiLZpk6eSn/Kc79XqPWSgWCvK/YesiwSBRpS mwB0+Wviz5/mA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 06/29] x86/boot/e820: Make the field separator space character part of e820_print_type() Date: Mon, 21 Apr 2025 20:51:46 +0200 Message-ID: <20250421185210.3372306-7-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We are going to add more columns to the E820 table printout, so make e820_print_type()'s field separator (space character) part of the function itself. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index a8edfa375fbd..10bd10bd5672 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -187,15 +187,15 @@ void __init e820__range_add(u64 start, u64 size, enum= e820_type type) static void __init e820_print_type(enum e820_type type) { switch (type) { - case E820_TYPE_RAM: pr_cont("usable"); break; - case E820_TYPE_RESERVED: pr_cont("reserved"); break; - case E820_TYPE_SOFT_RESERVED: pr_cont("soft reserved"); break; - case E820_TYPE_ACPI: pr_cont("ACPI data"); break; - case E820_TYPE_NVS: pr_cont("ACPI NVS"); break; - case E820_TYPE_UNUSABLE: pr_cont("unusable"); break; + case E820_TYPE_RAM: pr_cont(" usable"); break; + case E820_TYPE_RESERVED: pr_cont(" reserved"); break; + case E820_TYPE_SOFT_RESERVED: pr_cont(" soft reserved"); break; + case E820_TYPE_ACPI: pr_cont(" ACPI data"); break; + case E820_TYPE_NVS: pr_cont(" ACPI NVS"); break; + case E820_TYPE_UNUSABLE: pr_cont(" unusable"); break; case E820_TYPE_PMEM: /* Fall through: */ - case E820_TYPE_PRAM: pr_cont("persistent (type %u)", type); break; - default: pr_cont("type %u", type); break; + case E820_TYPE_PRAM: pr_cont(" persistent (type %u)", type); break; + default: pr_cont(" type %u", type); break; } } =20 @@ -491,9 +491,9 @@ __e820__range_update(struct e820_table *table, u64 star= t, u64 size, enum e820_ty size =3D ULLONG_MAX - start; =20 end =3D start + size; - printk(KERN_DEBUG "e820: update [mem %#010Lx-%#010Lx] ", start, end - 1); + printk(KERN_DEBUG "e820: update [mem %#010Lx-%#010Lx]", start, end - 1); e820_print_type(old_type); - pr_cont(" =3D=3D> "); + pr_cont(" =3D=3D>"); e820_print_type(new_type); pr_cont("\n"); =20 @@ -568,7 +568,7 @@ u64 __init e820__range_remove(u64 start, u64 size, enum= e820_type old_type, bool size =3D ULLONG_MAX - start; =20 end =3D start + size; - printk(KERN_DEBUG "e820: remove [mem %#010Lx-%#010Lx] ", start, end - 1); + printk(KERN_DEBUG "e820: remove [mem %#010Lx-%#010Lx]", start, end - 1); if (check_type) e820_print_type(old_type); pr_cont("\n"); --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 67EE21EF36E for ; Mon, 21 Apr 2025 18:53:09 +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=1745261589; cv=none; b=bi5gOZIu/mBfJhFG/HR1oZINdql37CKZTgAyyRHvnKdRRKdgyj+oREaVeR68PtVuwGT1kfWmSeuLzlpoO8Mnk+r+PViMBBvB6cT0gGXrkP0pGN6CWsan7BL28PR+X17EqrfMkSBSdl5norMLwJOwNgbqNxsiH8xqfYveZrHUMMY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261589; c=relaxed/simple; bh=YQ8Vkp7xUxca1fHWy6XPMau4fK6VgAz+OileZil+wic=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TvJETCsfM5770/iNCiltLgHBX/32u5MWO7K0OFeR/0lNT/7pDLP6tfLnaH85kzt93AZr+DHc4i2sT12kGVHzmSctYPwq8u1lB1+NwE3mbZ7GQsckfbmR0hZQeLaqHbPvk3CkmhnedxzPBD1HS/ZXA7c+6UxrrzREXdWtJ/Kns3Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WVia2pXo; 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="WVia2pXo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1794C4CEF2; Mon, 21 Apr 2025 18:53:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261589; bh=YQ8Vkp7xUxca1fHWy6XPMau4fK6VgAz+OileZil+wic=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WVia2pXoQlMwQuxWQqGOLHs3v9g1GnXOcFJaExlhwK2ds+MU3lKcVUheLf/m4H5iJ EAbcWgjp/arxhdIhFc7vYx9UpIKDXotf2wu35l2bGlV1hzNkBWK0pTtJK/wCHhMFGa 8/lBt6r3Wn/C0nRyRuFjmzpqyflc8ou+Bom59AD7M3WFsd+lqYC7QcgyMka2e29oGY 35N95AW6HYcT77iJ33L/R/1AOLipdxxWjtL+FfhfzIS98rcO0hIZZ8m9qJUzw4xiab JGABTBJoJKm1G8DfuRCRHwmbtiFowzXpzpJbWtKHIPw7hCyB1RP3vtotNE75V3LaQn a/dhU4+hjY7eg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 07/29] x86/boot/e820: Print out sizes of E820 memory ranges Date: Mon, 21 Apr 2025 20:51:47 +0200 Message-ID: <20250421185210.3372306-8-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Before: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved After: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] 639 KB kernel us= able RAM BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] 1 KB reserved BIOS-e820: [gap 0x00000000000a0000-0x00000000000effff] 320 KB ... BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] 64 KB reserved BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] 1.9 GB kernel us= able RAM BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] 144 KB reserved BIOS-e820: [gap 0x0000000080000000-0x00000000afffffff] 768 MB ... BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] 256 MB reserved BIOS-e820: [gap 0x00000000c0000000-0x00000000fed1bfff] 1005.1 MB ... BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] 16 KB reserved BIOS-e820: [gap 0x00000000fed20000-0x00000000feffbfff] 2.8 MB ... BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] 16 KB reserved BIOS-e820: [gap 0x00000000ff000000-0x00000000fffbffff] 15.7 MB ... BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] 256 KB reserved BIOS-e820: [gap 0x0000000100000000-0x000000fcffffffff] 1008 GB ... BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] 12 GB reserved Note how a 1-digit precision field is printed out if a range is fractional in its largest-enclosing natural size unit. So the "256 MB" and "12 GB" fields above denote exactly 256 MB and 12 GB regions, while "1.9 GB" signals the region's fractional nature and it being just below 2GB. Printing E820 maps with such details visualizes 'weird' ranges at a glance, and gives users a better understanding of how large the various ranges are, without having to perform hexadecimal subtraction in their minds. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) (cherry picked from commit d1ac6b8718575a7ea2f0a1ff347835a8879df673) --- arch/x86/kernel/e820.c | 47 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 10bd10bd5672..8ee89962fcbf 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -199,6 +199,41 @@ static void __init e820_print_type(enum e820_type type) } } =20 +/* + * Print out the size of a E820 region, in human-readable + * fashion, going from KB, MB, GB to TB units. + * + * Print out fractional sizes with a single digit of precision. + */ +static void e820_print_size(u64 size) +{ + if (size < SZ_1M) { + if (size & (SZ_1K-1)) + pr_cont(" %4llu.%01llu KB", size/SZ_1K, 10*(size & (SZ_1K-1))/SZ_1K); + else + pr_cont(" %4llu KB", size/SZ_1K); + return; + } + if (size < SZ_1G) { + if (size & (SZ_1M-1)) + pr_cont(" %4llu.%01llu MB", size/SZ_1M, 10*(size & (SZ_1M-1))/SZ_1M); + else + pr_cont(" %4llu MB", size/SZ_1M); + return; + } + if (size < SZ_1T) { + if (size & (SZ_1G-1)) + pr_cont(" %4llu.%01llu GB", size/SZ_1G, 10*(size & (SZ_1G-1))/SZ_1G); + else + pr_cont(" %4llu GB", size/SZ_1G); + return; + } + if (size & (SZ_1T-1)) + pr_cont(" %4llu.%01llu TB", size/SZ_1T, 10*(size & (SZ_1T-1))/SZ_1T); + else + pr_cont(" %4llu TB", size/SZ_1T); +} + static void __init e820__print_table(const char *who) { u64 range_end_prev =3D 0; @@ -215,14 +250,22 @@ static void __init e820__print_table(const char *who) if (range_start < range_end_prev) pr_info("BUG: out of order E820 entry!\n"); =20 + /* Print gaps, if any: */ if (range_start > range_end_prev) { - pr_info("%s: [gap %#018Lx-%#018Lx]\n", + u64 gap_size =3D range_start - range_end_prev; + + pr_info("%s: [gap %#018Lx-%#018Lx]", who, range_end_prev, range_start-1); + + e820_print_size(gap_size); + pr_cont(" ...\n"); } =20 - pr_info("%s: [mem %#018Lx-%#018Lx] ", who, range_start, range_end-1); + /* Print allocated ranges: */ + pr_info("%s: [mem %#018Lx-%#018Lx]", who, range_start, range_end-1); + e820_print_size(entry->size); e820_print_type(entry->type); pr_cont("\n"); =20 --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 98BA21EF39E for ; Mon, 21 Apr 2025 18:53:12 +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=1745261592; cv=none; b=nPCW/Hbpf4+LRyn6CGbSBrAHNKhUGEhPfdUkQJae2c7sZ5J52lO52a1J4FguPMP3ABrBm22JJdwCpB3EGrAKjpTrXoGgr1hpwXMU49FYtlhSqcq1P2X+tExAL7mtmw7tmddnLJ3IQgAWf5pLelkaWAxDNdmDYtWaKQMyBmW3gjY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261592; c=relaxed/simple; bh=X4GaBt+qisLszUoLlQoX6Qj0Kt8pfGVMPHII7noTzDc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K5wu5bPSmWV+j1U4V/sBi2KZ24D46a39SzrRXfiy+FgQh5dxNmWFKfZf9q1Jbt5VDHzn6I0H1fw31UA79H5XuDuLJMGPWfP9Hs+8oZRT68OEVckYysbkFOjx/7RceLfImpDFW9WeJ+STfYlnfgtA0uwfTEvIC4Mx2CX39TArt5o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F7eQBCNu; 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="F7eQBCNu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9C11C4CEEF; Mon, 21 Apr 2025 18:53:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261592; bh=X4GaBt+qisLszUoLlQoX6Qj0Kt8pfGVMPHII7noTzDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F7eQBCNuuCtELnyIeMblnZKWZc2iHEo53jdZG6af1ZOCbohEE5zZcsEegWjRbdbZ4 UEQbhJZkqikFFSmkqUHd0vdnnzpJzh3o70GE2NtJlwhtiNPvo7PMtclDqxLXMTtHRo yiMJk7UaJcQ7G+6o+G75sqPAjpPd4pLjPMe/NRPGzRVfC3QSslbDP3wZDE/bu1Rt1y 5nV7RKoJ1Qsx/FsSXd0pECjXIN0pQ0IfzVrJaupEVVp4Wsf01JOujl2BPDRpBbFSay bbLu0V4sYGacFamDpLna8w7RLbx+k1cZlZzcc+dWNIKkMi36NBhxy4dhwH6i4V+aLG g1UIbN74X/wWQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 08/29] x86/boot/e820: Print E820_TYPE_RAM entries as ... RAM entries Date: Mon, 21 Apr 2025 20:51:48 +0200 Message-ID: <20250421185210.3372306-9-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" So it is a bit weird that the actual RAM entries of the E820 table are not actually called RAM, but 'usable': BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] 1.9 GB usable 'usable' is pretty passive-aggressive in that context and ambiguous, most E820 entries denote 'usable' address ranges - reserved ranges may be used by devices, or the platform. Clarify and disambiguate this by making the boot log entry explicitly say 'kernel usable RAM': BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] 1.9 GB kernel us= able RAM Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 8ee89962fcbf..99f997ae88dc 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -187,7 +187,7 @@ void __init e820__range_add(u64 start, u64 size, enum e= 820_type type) static void __init e820_print_type(enum e820_type type) { switch (type) { - case E820_TYPE_RAM: pr_cont(" usable"); break; + case E820_TYPE_RAM: pr_cont(" kernel usable RAM"); break; case E820_TYPE_RESERVED: pr_cont(" reserved"); break; case E820_TYPE_SOFT_RESERVED: pr_cont(" soft reserved"); break; case E820_TYPE_ACPI: pr_cont(" ACPI data"); break; --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 7AF271EFFB0 for ; Mon, 21 Apr 2025 18:53:15 +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=1745261595; cv=none; b=qguKhFauVpu1veLUdPPNjgyoUxiv5O2bM/w1U3iWSnp+W8UNZ7hUp8ND+YLwl1YX71lGTqu9bfqZewytSKKarG9MnGnCsmnCEdjVsknjaV+08dH66cegCvmLWc8s8F47wLuo+CcL6IbBvJle0S/FLsq1CPkBYuh2/TFcNx9gZc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261595; c=relaxed/simple; bh=Zba+SDZBntbSqtZLY0JNtOwiAkFgLj0N+rqExNZHhg0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=moLqu0xRhhU48pSnQuBHQYdPOBww2+fT59KMXAbLLJpGbza7X7CGMpr7Ao4vTGxqkdRKbjjI9VDdR95Cz+I4pJUyE9bsuhiFW5eSGkj/CIJS/Kn/euzKCsq9yvPnQVr3BSlnY9gJY5lubdonHqAj1XqtF7DUIxAa49cV9moKEco= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MJcHPLUH; 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="MJcHPLUH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 811DCC4CEE4; Mon, 21 Apr 2025 18:53:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261594; bh=Zba+SDZBntbSqtZLY0JNtOwiAkFgLj0N+rqExNZHhg0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MJcHPLUHCNOgqlUNVbFH2nyvfMx1B6jEU2A3kdWV4m6vggMvghO+B4Q+hepfgHmNv eAlBcXp9ZDPcfYBPLH7Mt8DI91EXry3oMfZYheFzqrConqTmOIiSt2z9SxQnOV9MbZ VSCkiTcmMsOn4vgcOsERsUPoSLPCkZogAYAXWTtvJzUJHPx/KnJv3XPwlGnhKysB5O BkhNcRmdnE80VTKQ11haRV0oIZRGTAs6KvT0tRZw86nPG5bM9e7hA2xbkZSuFUkpAt FCLiNzH5bZCvcWmprZcFe+iWpHgTukEDPn3UWFjDzGfkM3HW1WkZCFMRcq1u4LBFLW XyB/b6f1umAMw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 09/29] x86/boot/e820: Call the PCI gap a 'gap' in the boot log printout Date: Mon, 21 Apr 2025 20:51:49 +0200 Message-ID: <20250421185210.3372306-10-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" It is a bit weird and inconsistent that the PCI gap is advertised during bootup as 'mem'ory: [mem 0xc0000000-0xfed1bfff] available for PCI devices ^^^ It's not really memory, it's a gap that PCI devices can decode and use and they often do not map it to any memory themselves. So advertise it for what it is, a gap: [gap 0xc0000000-0xfed1bfff] available for PCI devices Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 99f997ae88dc..3eab0908ca71 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -741,7 +741,7 @@ __init void e820__setup_pci_gap(void) */ pci_mem_start =3D gapstart; =20 - pr_info("[mem %#010lx-%#010lx] available for PCI devices\n", + pr_info("[gap %#010lx-%#010lx] available for PCI devices\n", gapstart, gapstart + gapsize - 1); } =20 --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 DFB4D1F03D9 for ; Mon, 21 Apr 2025 18:53:17 +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=1745261598; cv=none; b=tq4slNbv1TIAHLw/5K9dRvdBnE0h9OWIGieI7xmwcyVaWAyhiP/bD9K6/W8maqHWTTr4pCKMhfkbc4tdtcZTwIq8qNl67pjjUYzrVKpe1ROslkhiS0vlQpFym0vLU47KmtDAJGzMg8ZSR53z36H654XvIGhArkHsU91bqQWFZtI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261598; c=relaxed/simple; bh=GoqoUKEOL5IUWnXmEDfw86Ld9dJCSES2ioFEM/HLjOQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DMiI4sTdbYRxmxWWQnQ2JltsUB0kKdTPZw1DBbBGdgsaM8A2gF+ao+CaVLHE1GrXKwEK9y6Mnao/VXdhq5ip8oAKB9L5LppPrFsxI7Lc9zsxorZGH9jEXtxjHcSvNFnJCuzh/77MfkzeF8c+nNLe+6wpD+lLVZwPlyhqGu/QCYM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Voh5ewVl; 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="Voh5ewVl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5515FC4CEEF; Mon, 21 Apr 2025 18:53:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261597; bh=GoqoUKEOL5IUWnXmEDfw86Ld9dJCSES2ioFEM/HLjOQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Voh5ewVlaFS1w/yX0iZogeIJHOQjg8klS3jZ9ynZIRhKBGKcQTxqtiDxO3Ewpzfv1 dv5wgTxe+xkrUtDyI7ZuOqWoldBEjr7hfIsRbZlxUbA55/oIReFcSc6/BonCdNFHh+ HyI3uHQjXW+OLXd+9p3XTYKEPEk+xQvu7v5oohWGL9RI567l7gqY04RiFiLaRFaBpz 1XdrqWhlep9CGVFVapSU9PFniyGPpkQqNH6HjU31nmTPMc4uZYqJG84qFuFxDVDTJj 0PIHqI6HSObKy25li4hWbb79bhJvQf1/wggP3Ex4sEP1w1nX36434Rg5PJB/gkIiaH QBv7sNC6WeHBw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 10/29] x86/boot/e820: Use 'u64' consistently instead of 'unsigned long long' Date: Mon, 21 Apr 2025 20:51:50 +0200 Message-ID: <20250421185210.3372306-11-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" There's a number of structure fields and local variables related to E820 entry physical addresses that are defined as 'unsigned long long', but then are compared to u64 fields. Make the types all consistently u64. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 3eab0908ca71..7d100e653554 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -338,7 +338,7 @@ struct change_member { /* Pointer to the original entry: */ struct e820_entry *entry; /* Address for this change point: */ - unsigned long long addr; + u64 addr; }; =20 static struct change_member change_point_list[2*E820_MAX_ENTRIES] __initda= ta; @@ -386,7 +386,7 @@ int __init e820__update_table(struct e820_table *table) struct e820_entry *entries =3D table->entries; u32 max_nr_entries =3D ARRAY_SIZE(table->entries); enum e820_type current_type, last_type; - unsigned long long last_addr; + u64 last_addr; u32 new_nr_entries, overlap_entries; u32 i, chg_idx, chg_nr; =20 @@ -683,13 +683,13 @@ static void __init e820__update_table_kexec(void) */ static int __init e820_search_gap(unsigned long *gapstart, unsigned long *= gapsize) { - unsigned long long last =3D MAX_GAP_END; + u64 last =3D MAX_GAP_END; int i =3D e820_table->nr_entries; int found =3D 0; =20 while (--i >=3D 0) { - unsigned long long start =3D e820_table->entries[i].addr; - unsigned long long end =3D start + e820_table->entries[i].size; + u64 start =3D e820_table->entries[i].addr; + u64 end =3D start + e820_table->entries[i].size; =20 /* * Since "last" is at most 4GB, we know we'll --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 E2DDA1F09AC for ; Mon, 21 Apr 2025 18:53:20 +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=1745261601; cv=none; b=MhLkov7Sc8SPMzryOt+vOI+EvrCj5/ERf4ruqfp+yCr8P34e/invDw1xGLhLrPkaJaqC1zK5OkYckivI5hCYG9psx0heHpog6f3Y4m0zibpAh6CWQihhDnQCSOOs/wZTjUK/q++RYr910ssP5D3R9z/bKfPQQ5BNVNw80S8uhBI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261601; c=relaxed/simple; bh=/yo+hTFhPqTBW5TtbJV/pbX5P9QGqDQIM5lkxby/Kxs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gGAF2XhRaB0jHYxXckyXldb9jR/JDS0Wx4Lc/RfAYdJ95aOLqm7yphQuxlUI7hKLRvhpBOvu/FBSAH6/nIvdohzNVRjF9rqQwLKUOxj8UwDT5IK6ZbaBJUY7nn4HIEkWPFg4KI+qufdqkKKBKgBvYUMH0px8b8bGv7B16LCsPG8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JPAy/Teb; 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="JPAy/Teb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29205C4CEEB; Mon, 21 Apr 2025 18:53:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261600; bh=/yo+hTFhPqTBW5TtbJV/pbX5P9QGqDQIM5lkxby/Kxs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JPAy/Teb75tONTMAsi6A0lE2CnftXwiW+sCIo16ZNS9mEvYXAHMHeTOe3jl7B3eQ1 pp2/hPig5V//OWRaqMMc9IBNUjdsLW/lHmhSLfwNtCz0W53fFuPRTBhrm82oYXto8f qeiiKi38cjo1VfwPcp95cMsr1PLeYnU+MK+pEiA4V91vZKcF3Ygps5neqOjavk9UbG fz0564wAlatqt+ONgfjTr6IVZdiXvhU3Gs7GfwhO5b9oSLgtayELOFVltufz5oPprq ff4iIdyK1zJbzYtpmOCZSxBnNYcPoxIjnif34JIRt38gmjzqajA3Nb51ZZzDf0BwfQ 1nZ2/XOlrB6GQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 11/29] x86/boot/e820: Remove pointless early_panic() indirection Date: Mon, 21 Apr 2025 20:51:51 +0200 Message-ID: <20250421185210.3372306-12-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" early_panic() is a pointless wrapper around panic(): static void __init early_panic(char *msg) { early_printk(msg); panic(msg); } panic() will already do a printk() of 'msg', and an early_printk() if earlyprintk is enabled. There's no need to print it separately. Remove the function. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 7d100e653554..8fcf4edd832e 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -935,12 +935,6 @@ unsigned long __init e820__end_of_low_ram_pfn(void) return e820__end_ram_pfn(1UL << (32 - PAGE_SHIFT)); } =20 -static void __init early_panic(char *msg) -{ - early_printk(msg); - panic(msg); -} - static int userdef __initdata; =20 /* The "mem=3Dnopentium" boot option disables 4MB page tables on 32-bit ke= rnels: */ @@ -1060,7 +1054,7 @@ void __init e820__finish_early_params(void) { if (userdef) { if (e820__update_table(e820_table) < 0) - early_panic("Invalid user supplied memory map"); + panic("Invalid user supplied memory map"); =20 pr_info("user-defined physical RAM map:\n"); e820__print_table("user"); --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 BB6DD1F0E4F for ; Mon, 21 Apr 2025 18:53:23 +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=1745261603; cv=none; b=jucbqvPiHRqUnTkZicnk6fnnzgnS4Omi6RFEGvqDXNz32ewQR2xPknSqfTk3zj/LaCyojHkcqfqipq+ZsBhGNdRvkPbQaSCQf9JM5i8TrZrRlsXM9C5N66u6zphSEE+eM8H2AT6BDwXBuCo09dYGTSfK21MgkK7v8k0JzQakAXY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261603; c=relaxed/simple; bh=FdRk1E1sd13LPXFtF8M3rZN5HzbOEhTA/TZIuR7q/Sk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W17TCVDqxWs0jb/704UTeFCTvlWErNa47Vtt1SqeXVZ6NqmzVpbniiicL+BNPAiZJ3gi4hslAaa9HS9khRnR3OAoOSmG1utgNa8xQuL7VqshU9hkhd6InVxfXRVPuuTEDdEV8BEsjNKOQHpTRM5Du88ED3yn4FBMm2y/Rd0fSN4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EZoZmDae; 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="EZoZmDae" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB29AC4CEEC; Mon, 21 Apr 2025 18:53:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261603; bh=FdRk1E1sd13LPXFtF8M3rZN5HzbOEhTA/TZIuR7q/Sk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EZoZmDae00YVthCR4q5yPaQFYGkH4OXtASxbZR3HhJnUEfeNlmdnWhvLoPAnB8Nyx qRaz6/eobmiQrPce+zyVbAfxUvV7gR5n1mL/m/t3KD1riKNI3oVSDaqvLCVgdeMBgd QSKzIuWJta1ArUyxZR3QYVN+X13bhxleXY4+xxRYfF86On4Xef74ELbmlM9GelJp5D /icVIPBzELhPr2rKEhYdIlbcQ+KVB+iwPC6pqa1/bcAtn8SIUkgN7QDOm9fu0U/rg7 TFpWqPcLzogFUBVR5A/WjmmH9DCxc0Io5IedcMtmRqpM1xpEf22ATPgIkle1gTGZDL 03nR6bDHi8VSA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 12/29] x86/boot/e820: Clean up confusing and self-contradictory verbiage around E820 related resource allocations Date: Mon, 21 Apr 2025 20:51:52 +0200 Message-ID: <20250421185210.3372306-13-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" So the E820 code has a rather confusing area of code at around e820__reserve_resources(), which is, by its plain reading, rather self-contradictory. For example, the comment explaining e820__reserve_resources() claims: - '* Mark E820 reserved areas as busy for the resource manager' By 'E820 reserved areas' one can naively conclude that it's talking about E820_TYPE_RESERVED areas - while those areas are treated in exactly the opposite fashion by do_mark_busy(): switch (type) { case E820_TYPE_RESERVED: case E820_TYPE_SOFT_RESERVED: case E820_TYPE_PRAM: case E820_TYPE_PMEM: return false; Ie. E820_TYPE_RESERVED areas are *not* marked busy for the resource manager, because E820_TYPE_RESERVED areas are device regions that might eventually be claimed by a device driver. This type of confusion permeates this whole area of code, making it exceedingly difficult to read (for me at least). So untangle it bit by bit: - Instead of talking about ambiguous 'reserved areas', talk about 'E820 device address regions' instead, and 'register'/'lock' them. - The do_mark_busy() function is a misnomer as well, because despite its name it 'does' nothing - it only determines what type of resource handling an E820 type should receive from the kernel. Rename it to e820_device_region() and negate its meaning, to avoid the 'busy/reserved' confusion. Because that's what this code is really about: filtering out device regions such as E820_TYPE_RESERVED, E820_TYPE_PRAM, E820_TYPE_PMEM, etc., and allowing them to be claimed by device drivers later on. - All other E820 regions (system regions) are registered and locked early on, before the PCI resource manager does its search for device BAR addresses, etc. Also fix this somewhat misleading comment: /* * Try to bump up RAM regions to reasonable boundaries, to * avoid stolen RAM: */ and explain that here we register artificial 'gap' resources at the end of suspiciously sized RAM regions, as heuristics to try to avoid buggy firmware with undeclared 'stolen RAM' regions: /* * Create additional 'gaps' at the end of RAM regions, * rounding them up to 64k/1MB/64MB boundaries, should * they be weirdly sized, and register extra, locked * resource regions for them, to make sure drivers * won't claim those addresses. * * These are basically blind guesses and heuristics to * avoid resource conflicts with broken firmware that * doesn't properly list 'stolen RAM' as a system region * in the E820 map. */ Also improve the printout of this extra resource a bit: make the message more unambiguous, and upgrade it from pr_debug() (where very few people will see it), to pr_info() (where it will make it into the syslog on default distro configs). Also fix spelling and improve comment placement. No change in functionality intended. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 55 +++++++++++++++++++++++++++++++++-------------= ---- 1 file changed, 37 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 8fcf4edd832e..484419711ecf 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -1106,37 +1106,44 @@ static unsigned long __init e820_type_to_iores_desc= (struct e820_entry *entry) } } =20 -static bool __init do_mark_busy(enum e820_type type, struct resource *res) +/* + * We assign one resource entry for each E820 map entry: + */ +static struct resource __initdata *e820_res; + +/* + * Is this a device address region that should not be marked busy? + * (Versus system address regions that we register & lock early.) + */ +static bool __init e820_device_region(enum e820_type type, struct resource= *res) { - /* this is the legacy bios/dos rom-shadow + mmio region */ + /* This is the legacy BIOS/DOS ROM-shadow + MMIO region: */ if (res->start < (1ULL<<20)) - return true; + return false; =20 /* * Treat persistent memory and other special memory ranges like - * device memory, i.e. reserve it for exclusive use of a driver + * device memory, i.e. keep it available for exclusive use of a + * driver: */ switch (type) { case E820_TYPE_RESERVED: case E820_TYPE_SOFT_RESERVED: case E820_TYPE_PRAM: case E820_TYPE_PMEM: - return false; + return true; case E820_TYPE_RAM: case E820_TYPE_ACPI: case E820_TYPE_NVS: case E820_TYPE_UNUSABLE: default: - return true; + return false; } } =20 /* - * Mark E820 reserved areas as busy for the resource manager: + * Mark E820 system regions as busy for the resource manager: */ - -static struct resource __initdata *e820_res; - void __init e820__reserve_resources(void) { int i; @@ -1162,18 +1169,18 @@ void __init e820__reserve_resources(void) res->desc =3D e820_type_to_iores_desc(entry); =20 /* - * Don't register the region that could be conflicted with - * PCI device BAR resources and insert them later in - * pcibios_resource_survey(): + * Skip and don't register device regions that could be conflicted + * with PCI device BAR resources. They get inserted later in + * pcibios_resource_survey() -> e820__reserve_resources_late(): */ - if (do_mark_busy(entry->type, res)) { + if (!e820_device_region(entry->type, res)) { res->flags |=3D IORESOURCE_BUSY; insert_resource(&iomem_resource, res); } res++; } =20 - /* Expose the kexec e820 table to the sysfs. */ + /* Expose the kexec e820 table to sysfs: */ for (i =3D 0; i < e820_table_kexec->nr_entries; i++) { struct e820_entry *entry =3D e820_table_kexec->entries + i; =20 @@ -1207,6 +1214,10 @@ void __init e820__reserve_resources_late(void) int i; struct resource *res; =20 + /* + * Register device address regions listed in the E820 map, + * these can be claimed by device drivers later on: + */ res =3D e820_res; for (i =3D 0; i < e820_table->nr_entries; i++) { if (!res->parent && res->end) @@ -1215,8 +1226,16 @@ void __init e820__reserve_resources_late(void) } =20 /* - * Try to bump up RAM regions to reasonable boundaries, to - * avoid stolen RAM: + * Create additional 'gaps' at the end of RAM regions, + * rounding them up to 64k/1MB/64MB boundaries, should + * they be weirdly sized, and register extra, locked + * resource regions for them, to make sure drivers + * won't claim those addresses. + * + * These are basically blind guesses and heuristics to + * avoid resource conflicts with broken firmware that + * doesn't properly list 'stolen RAM' as a system region + * in the E820 map. */ for (i =3D 0; i < e820_table->nr_entries; i++) { struct e820_entry *entry =3D &e820_table->entries[i]; @@ -1232,7 +1251,7 @@ void __init e820__reserve_resources_late(void) if (start >=3D end) continue; =20 - printk(KERN_DEBUG "e820: reserve RAM buffer [mem %#010llx-%#010llx]\n", = start, end); + pr_info("e820: register RAM buffer resource [mem %#010llx-%#010llx]\n", = start, end); reserve_region_with_split(&iomem_resource, start, end, "RAM buffer"); } } --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 30B191F1317 for ; Mon, 21 Apr 2025 18:53:26 +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=1745261606; cv=none; b=t6+ohemgYqci/y6wir6Hohm4UQfMaLFjh2YSCybgiO09CXwK2po0+ulxqrK2PUX2AcVFjStSNP92AO/GwVCBZpinwSnAPyZJF4rZF3fi8/70pTFRX7nZFi4HhFTPTGult0p0Jq4+FY7O10S86R9IHPwWnOCehByry1dOkIH8hXU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261606; c=relaxed/simple; bh=llkZNwRDTXnM7RyZfx311thpcdgrfSKxzjxOVFqcJJ0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Eo0SoFFacKtn0/OogtVzu9OgZLKZeHDO7p17jf4rLwRP0THMirqt4YYRqVVctjXhwf4wMMV3VGdoVRj/dcjN31nDPVgiPNCDzGawVbXzh59JMhB2KHu5brfe3Bnvp96KAmy3viFMPtz1TaKBOZ7djcY3q5azkUyqejXA/DCC+Pc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GAf034F0; 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="GAf034F0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DF14C4CEEB; Mon, 21 Apr 2025 18:53:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261606; bh=llkZNwRDTXnM7RyZfx311thpcdgrfSKxzjxOVFqcJJ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GAf034F0Apeab9olix68xcaE9/Bq/3wKK/13vKGjS1xbGxWS/eJ1UcwKSUZ0Bnxvj NHDSfNRkDFrqx2LSVviqujiMiOePdjAol/ejuanWS1iT1Fu+OxaY3DJEoU6RQb4Ln3 6U0+J6iKMVZQeyKEIVpBTdMS3PAD/EA7QOsP9OeQYAYNmaszfdp1nKQ95L3vTjgC7l Q61xBki7W/9tfWZ7u7VxaN6e7SUlz6/lW6f6GIV3y/aZHZb/VYqikmngXa1K3wIrZr Tq4Wkjb11O22oPUhlTJv3ueR2OL1EGwD7XT4J2TtaF7W/gWkN3/fdr10gXsRFFoiW3 3iP41nQN8cQDg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 13/29] x86/boot/e820: Improve e820_print_type() messages Date: Mon, 21 Apr 2025 20:51:53 +0200 Message-ID: <20250421185210.3372306-14-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For E820_TYPE_RESERVED, print: 'reserved' -> 'device reserved' For E820_TYPE_PRAM and E820_TYPE_PMEM: 'persistent' -> 'persistent RAM' Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 484419711ecf..ae05161896d4 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -187,15 +187,15 @@ void __init e820__range_add(u64 start, u64 size, enum= e820_type type) static void __init e820_print_type(enum e820_type type) { switch (type) { - case E820_TYPE_RAM: pr_cont(" kernel usable RAM"); break; - case E820_TYPE_RESERVED: pr_cont(" reserved"); break; - case E820_TYPE_SOFT_RESERVED: pr_cont(" soft reserved"); break; - case E820_TYPE_ACPI: pr_cont(" ACPI data"); break; - case E820_TYPE_NVS: pr_cont(" ACPI NVS"); break; - case E820_TYPE_UNUSABLE: pr_cont(" unusable"); break; + case E820_TYPE_RAM: pr_cont(" kernel usable RAM"); break; + case E820_TYPE_RESERVED: pr_cont(" device reserved"); break; + case E820_TYPE_SOFT_RESERVED: pr_cont(" soft reserved"); break; + case E820_TYPE_ACPI: pr_cont(" ACPI data"); break; + case E820_TYPE_NVS: pr_cont(" ACPI NVS"); break; + case E820_TYPE_UNUSABLE: pr_cont(" unusable"); break; case E820_TYPE_PMEM: /* Fall through: */ - case E820_TYPE_PRAM: pr_cont(" persistent (type %u)", type); break; - default: pr_cont(" type %u", type); break; + case E820_TYPE_PRAM: pr_cont(" persistent RAM (type %u)", type); break; + default: pr_cont(" type %u", type); break; } } =20 --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 048AB1EBFE0 for ; Mon, 21 Apr 2025 18:53:29 +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=1745261609; cv=none; b=o9S2+6FOJIg63MU0cVcl+BsdgwbAEkWNSLzQc3gzbr9gxQxalpRQkK5KiezfnBJLiv47b9DdWyRoBbO99QS9bqqTrlvP4Zvc7mycVWOB+smtm69y5xT001dz2iMw5Tpvm+PzqZc43wTiRkPZ/ksNfHjLzjTCwYBcXooLWqFOwcs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261609; c=relaxed/simple; bh=fup/Ks0ZisKAHfo7PloZj7/wqfacxOjMZEqtnF76wu8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lATl3SpOd1lU5q+D6pqbVtvpoI8mP1ggayNArV9jzDtouBglyMJbwDzf57OiyCQt2Uzhl5m0+Wm/aHtXi2xbk2eoSXUMs7DxBAJdbbvd8i222UrxMj39F4deJxTy+8agmF9chqnaBKantiQd8U2gGEgG6VBGcoHQuRg269pnbxY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=to9pPqu8; 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="to9pPqu8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 706AAC4CEEC; Mon, 21 Apr 2025 18:53:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261608; bh=fup/Ks0ZisKAHfo7PloZj7/wqfacxOjMZEqtnF76wu8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=to9pPqu8EgLQYxybK31paryTYUn2m7VMYPB2IUtH0nBMJsGP1eSo+Rwks1XUDTENc Zn3D9eqz0hpRcBT0hO2NCA/WLtZx2W1swTR4Vlkf4OEzOixuhhBDE9e2G0eODnK67w ThG5p3vYgJGd4qIbyqBBIUKP0WNah5I8W7ckTKFvh57tLru85CrzTHpOFiWM7vYGE8 WVscDhE060+FFtZtpB/GVwvoinqwqYdowzVERhDxA/LFtO5xPzZ1NNiS6ntVwCAVQq fLYREFLA2xbZSvvFykPzK9VbmJz32eMtVwL+N+70nZQRht6VBYT+PIIKpp7R6l8nuh LRpMUK+ezMYHQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 14/29] x86/boot/e820: Clean up __e820__range_add() a bit Date: Mon, 21 Apr 2025 20:51:54 +0200 Message-ID: <20250421185210.3372306-15-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" - Use 'idx' index variable instead of a weird 'x' - Make the error message E820-specific - Group the code a bit better Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index ae05161896d4..6e626c4a3817 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -165,17 +165,18 @@ int e820__get_entry_type(u64 start, u64 end) */ static void __init __e820__range_add(struct e820_table *table, u64 start, = u64 size, enum e820_type type) { - int x =3D table->nr_entries; + int idx =3D table->nr_entries; =20 - if (x >=3D ARRAY_SIZE(table->entries)) { - pr_err("too many entries; ignoring [mem %#010llx-%#010llx]\n", - start, start + size - 1); + if (idx >=3D ARRAY_SIZE(table->entries)) { + pr_err("too many E820 table entries; ignoring [mem %#010llx-%#010llx]\n", + start, start + size-1); return; } =20 - table->entries[x].addr =3D start; - table->entries[x].size =3D size; - table->entries[x].type =3D type; + table->entries[idx].addr =3D start; + table->entries[idx].size =3D size; + table->entries[idx].type =3D type; + table->nr_entries++; } =20 --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 C82AE1EDA06 for ; Mon, 21 Apr 2025 18:53:31 +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=1745261611; cv=none; b=LrLJTT8G/aL5Dg9m0EUCyryXqGOtDV6k2LUNGdD4VGIN+OXIKpcgM2ixLa2tP7mAGdRx0u7SfPoAHCKd2HhScT58Mpuh2lW3I+NofdxxSaL0JSsHemJ6KRFo6ceWOyq09GGh8A5VsZyCcLVxJMu48J/02XuSguZVt1q9lL2s1fw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261611; c=relaxed/simple; bh=HLGOql75xlDf5fthG2gUAwDXCfaXYZ3U8aECs8xCrSU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tl00/KO6wByDmyyQzy0U12idj+nS9RYE7zthRsKUBoVWXpHZzR2pvziIyt93Hy2DZDRkqKJ1P4ur/7TIt2DqexfJIwvFW/gunKVvji/a23u/u5lBtkPQ6PzsyFEcEFrbGvWc3IZle8k0LuafBdmPHdJkEIc5QkkL2MiA1MFJZ+A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W3xlt108; 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="W3xlt108" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42E4FC4CEEB; Mon, 21 Apr 2025 18:53:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261611; bh=HLGOql75xlDf5fthG2gUAwDXCfaXYZ3U8aECs8xCrSU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W3xlt108og04TUfGGIZBFLDUGVQEO1zwmPCCsNpuHAiuyjLnC5Zx2COdVlVwOgYEO M6kMZk6E/vRcKyJndu5+I+vZ754FwZ8NK1R/hRHtDfjbpOjAmLceJWmDFyr7Rxz95w zOisHJ8zMvmZ8IJvuQT5dStWNPfHA1OQFVsQoFp21+3Z3Fk1uoE7oOH6SbjGEgvzQR wnmj5YXR5QGVo2hWUwoBY9FJXQjoOtQBlHe3YqosILetwyGu2f0OSbGp0oR/Jzz8+d kdxksQrNxAXnv+f+Q0DTSDX5sCY4T9ew2IAyBqrJ/x9gUnRcCaMUodx8Yy98bYJKW2 fDb+azdo7d7RA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 15/29] x86/boot/e820: Clean up __refdata use a bit Date: Mon, 21 Apr 2025 20:51:55 +0200 Message-ID: <20250421185210.3372306-16-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" So __refdata, like __init, is more of a storage class specifier, so move the attribute in front of the type, not after the variable name. This also aligns it vertically. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 6e626c4a3817..cb4e5349fd22 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -60,9 +60,9 @@ static struct e820_table e820_table_init __initdata; static struct e820_table e820_table_kexec_init __initdata; static struct e820_table e820_table_firmware_init __initdata; =20 -struct e820_table *e820_table __refdata =3D &e820_table_init; -struct e820_table *e820_table_kexec __refdata =3D &e820_table_kexec_init; -struct e820_table *e820_table_firmware __refdata =3D &e820_table_firmware_= init; +__refdata struct e820_table *e820_table =3D &e820_table_init; +__refdata struct e820_table *e820_table_kexec =3D &e820_table_kexec_init; +__refdata struct e820_table *e820_table_firmware =3D &e820_table_firmware_= init; =20 /* For PCI or other memory-mapped resources */ unsigned long pci_mem_start =3D 0xaeedbabe; --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 A90C31F1906 for ; Mon, 21 Apr 2025 18:53:34 +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=1745261614; cv=none; b=c3p6ixgxr7sfAAYGz0VC+JJUMVFQu8BHPvIrN5WU3pOHJzy9VSWftPcXYXkzfonuCzmmk1a+iyqu+rsJ29RDgLi4Lf0ihAjex+GtrTKpHFhhURdzIaD7TkJU/NI+bRKwwLvI3uEhx28r+qtdn/R3+x5ROeuti2fpaIRcaS3yQ20= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261614; c=relaxed/simple; bh=JV23K5UID/SGrdWU1EzCvLuSQ1bEeNBQX5LBK1pmoeY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pmBENmfx/A/JqwiqwQkRf6dw3fVoANwGs78QUH+b1sAc4MpPYmsHfqMWJ3TNqyzVFynyuJVVLFMu7cA/53BmEoEVi8DCJFuTn2u/Q8sggnj0PkcwiEnU2oMTW5qaXELtXuPvzuaw6OyFxeacZBG4wy7ZtdE8tmpFfX3+zxdYvj8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fNwEucwk; 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="fNwEucwk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1902BC4CEF0; Mon, 21 Apr 2025 18:53:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261614; bh=JV23K5UID/SGrdWU1EzCvLuSQ1bEeNBQX5LBK1pmoeY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fNwEucwkjdKKKxfI6lY4rQ6hhdjomRo8STDfXzFaavVdKH7nsykrJarmloUCbaDEb WTBkMnwzelzx9rsUaXbaYAwOXx260mnW3yYnGzkYNgGbUOqzQeSwuuPmHWGA+HL/vo DX2F5ah4FSXdscB3qgXn0l5zUqfjZV6TNtaCcM9SZ1ckflMFI8kvJrFAUD4T6250R0 EIrsM9Wrb34QaBq+1vpB9z0LqICX6Cl6gwMSuw5+KDRVaDhUQ+fy9mzvZk6HeMuv1l wgPuFbWslsQ0FJYzIzlHkQUHj2YmQ5w3Q6mB/sE288JWLZ45nNdYXJhe0fT1ixuARq 4aiiVsjCYPC3w== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 16/29] x86/boot/e820: Remove unnecessary header inclusions Date: Mon, 21 Apr 2025 20:51:56 +0200 Message-ID: <20250421185210.3372306-17-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index cb4e5349fd22..158f9a46ba55 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -9,13 +9,11 @@ * quirks and other tweaks, and feeds that into the generic Linux memory * allocation code routines via a platform independent interface (memblock= , etc.). */ -#include #include #include #include #include #include -#include =20 #include #include --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 79B271F2C45 for ; Mon, 21 Apr 2025 18:53:37 +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=1745261617; cv=none; b=M3Ewm93Vifw7YckfSobZ/59xNzYGQjVtXSgM2xo/XXGHjfQUwot/aUzpQlosFFSeDvCJO0FPZWR7wdYvoOlyMaq6blws3poihlDwo6xlo7Go8PYsxL3YWctdMaPMMVIgirFwl0VAGvPffZHrsuiO9rHgk86SCDu1gnrtxi/IyOQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261617; c=relaxed/simple; bh=fCQu+gk3aJcQ+GQqT/viek+ThuSUtAcMaB9uW8cQlGk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LZmRYkeGbVQow0pcnmY8tLH1XTt6eRLNPF4CVewFQrgpzgCarFBk1j7/Nbs8iuQN9l+Ee5priFYIoCTa/wdjcN/lD88dj19QgtdGcQJSpdC2v18Ej7BA7alZ8sLLNJbXWMKzpbPT5uYX0MuE8OYm/6f+YxR4sF8+9vNlvzEubKw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nC74/ZzI; 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="nC74/ZzI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1503C4CEEA; Mon, 21 Apr 2025 18:53:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261617; bh=fCQu+gk3aJcQ+GQqT/viek+ThuSUtAcMaB9uW8cQlGk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nC74/ZzIC3rydPQdAOwWGn4fph2R/7ania8lvOd7sy5kxRPDy8Xblpc6ra2Qv59CW hXJH0z95/hw/h2oG9a67n11F7jmblJZ0lCtnFzcFV0p7GnhHVMU0sYcP2ZIZzS23OI W3hTI+OKwkUMIH7JHDB2GjzZ/Ek70uOhwZr8YtsYoYrCTce2DtcquiVxbAd9sY/YFn vmoUQ3jCOAd7O5Jci5IErOlOHTKwYim4VnZ2cXJEtJ4IhKUiS+s6hX8DArShuvCVRe iGZqzut9YRCyyAfqmoNEaGuk32gJBwzpO5PWELI3sP7S7QHzXt9QB1cySV/9YxPRFc L5jdP5MztwzIg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 17/29] x86/boot/e820: Standardize e820 table index variable names under 'idx' Date: Mon, 21 Apr 2025 20:51:57 +0200 Message-ID: <20250421185210.3372306-18-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 114 ++++++++++++++++++++++++---------------------= ---- 1 file changed, 57 insertions(+), 57 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 158f9a46ba55..919950d0f03d 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -75,10 +75,10 @@ EXPORT_SYMBOL(pci_mem_start); static bool _e820__mapped_any(struct e820_table *table, u64 start, u64 end, enum e820_type type) { - int i; + int idx; =20 - for (i =3D 0; i < table->nr_entries; i++) { - struct e820_entry *entry =3D &table->entries[i]; + for (idx =3D 0; idx < table->nr_entries; idx++) { + struct e820_entry *entry =3D &table->entries[idx]; =20 if (type && entry->type !=3D type) continue; @@ -110,10 +110,10 @@ EXPORT_SYMBOL_GPL(e820__mapped_any); static struct e820_entry *__e820__mapped_all(u64 start, u64 end, enum e820_type type) { - int i; + int idx; =20 - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D &e820_table->entries[i]; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D &e820_table->entries[idx]; =20 if (type && entry->type !=3D type) continue; @@ -236,10 +236,10 @@ static void e820_print_size(u64 size) static void __init e820__print_table(const char *who) { u64 range_end_prev =3D 0; - int i; + int idx; =20 - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D e820_table->entries + i; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D e820_table->entries + idx; u64 range_start, range_end; =20 range_start =3D entry->addr; @@ -387,7 +387,7 @@ int __init e820__update_table(struct e820_table *table) enum e820_type current_type, last_type; u64 last_addr; u32 new_nr_entries, overlap_entries; - u32 i, chg_idx, chg_nr; + u32 idx, chg_idx, chg_nr; =20 /* If there's only one memory region, don't bother: */ if (table->nr_entries < 2) @@ -396,26 +396,26 @@ int __init e820__update_table(struct e820_table *tabl= e) BUG_ON(table->nr_entries > max_nr_entries); =20 /* Bail out if we find any unreasonable addresses in the map: */ - for (i =3D 0; i < table->nr_entries; i++) { - if (entries[i].addr + entries[i].size < entries[i].addr) + for (idx =3D 0; idx < table->nr_entries; idx++) { + if (entries[idx].addr + entries[idx].size < entries[idx].addr) return -1; } =20 /* Create pointers for initial change-point information (for sorting): */ - for (i =3D 0; i < 2 * table->nr_entries; i++) - change_point[i] =3D &change_point_list[i]; + for (idx =3D 0; idx < 2 * table->nr_entries; idx++) + change_point[idx] =3D &change_point_list[idx]; =20 /* * Record all known change-points (starting and ending addresses), * omitting empty memory regions: */ chg_idx =3D 0; - for (i =3D 0; i < table->nr_entries; i++) { - if (entries[i].size !=3D 0) { - change_point[chg_idx]->addr =3D entries[i].addr; - change_point[chg_idx++]->entry =3D &entries[i]; - change_point[chg_idx]->addr =3D entries[i].addr + entries[i].size; - change_point[chg_idx++]->entry =3D &entries[i]; + for (idx =3D 0; idx < table->nr_entries; idx++) { + if (entries[idx].size !=3D 0) { + change_point[chg_idx]->addr =3D entries[idx].addr; + change_point[chg_idx++]->entry =3D &entries[idx]; + change_point[chg_idx]->addr =3D entries[idx].addr + entries[idx].size; + change_point[chg_idx++]->entry =3D &entries[idx]; } } chg_nr =3D chg_idx; @@ -437,9 +437,9 @@ int __init e820__update_table(struct e820_table *table) overlap_list[overlap_entries++] =3D change_point[chg_idx]->entry; } else { /* Remove entry from list (order independent, so swap with last): */ - for (i =3D 0; i < overlap_entries; i++) { - if (overlap_list[i] =3D=3D change_point[chg_idx]->entry) - overlap_list[i] =3D overlap_list[overlap_entries-1]; + for (idx =3D 0; idx < overlap_entries; idx++) { + if (overlap_list[idx] =3D=3D change_point[chg_idx]->entry) + overlap_list[idx] =3D overlap_list[overlap_entries-1]; } overlap_entries--; } @@ -449,9 +449,9 @@ int __init e820__update_table(struct e820_table *table) * 1=3Dusable, 2,3,4,4+=3Dunusable) */ current_type =3D 0; - for (i =3D 0; i < overlap_entries; i++) { - if (overlap_list[i]->type > current_type) - current_type =3D overlap_list[i]->type; + for (idx =3D 0; idx < overlap_entries; idx++) { + if (overlap_list[idx]->type > current_type) + current_type =3D overlap_list[idx]->type; } =20 /* Continue building up new map based on this information: */ @@ -524,7 +524,7 @@ static u64 __init __e820__range_update(struct e820_table *table, u64 start, u64 size, enum e= 820_type old_type, enum e820_type new_type) { u64 end; - unsigned int i; + unsigned int idx; u64 real_updated_size =3D 0; =20 BUG_ON(old_type =3D=3D new_type); @@ -539,8 +539,8 @@ __e820__range_update(struct e820_table *table, u64 star= t, u64 size, enum e820_ty e820_print_type(new_type); pr_cont("\n"); =20 - for (i =3D 0; i < table->nr_entries; i++) { - struct e820_entry *entry =3D &table->entries[i]; + for (idx =3D 0; idx < table->nr_entries; idx++) { + struct e820_entry *entry =3D &table->entries[idx]; u64 final_start, final_end; u64 entry_end; =20 @@ -602,7 +602,7 @@ u64 __init e820__range_update_table(struct e820_table *= t, u64 start, u64 size, /* Remove a range of memory from the E820 table: */ u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type= , bool check_type) { - int i; + int idx; u64 end; u64 real_removed_size =3D 0; =20 @@ -615,8 +615,8 @@ u64 __init e820__range_remove(u64 start, u64 size, enum= e820_type old_type, bool e820_print_type(old_type); pr_cont("\n"); =20 - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D &e820_table->entries[i]; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D &e820_table->entries[idx]; u64 final_start, final_end; u64 entry_end; =20 @@ -683,12 +683,12 @@ static void __init e820__update_table_kexec(void) static int __init e820_search_gap(unsigned long *gapstart, unsigned long *= gapsize) { u64 last =3D MAX_GAP_END; - int i =3D e820_table->nr_entries; + int idx =3D e820_table->nr_entries; int found =3D 0; =20 - while (--i >=3D 0) { - u64 start =3D e820_table->entries[i].addr; - u64 end =3D start + e820_table->entries[i].size; + while (--idx >=3D 0) { + u64 start =3D e820_table->entries[idx].addr; + u64 end =3D start + e820_table->entries[idx].size; =20 /* * Since "last" is at most 4GB, we know we'll @@ -814,11 +814,11 @@ void __init e820__memory_setup_extended(u64 phys_addr= , u32 data_len) */ void __init e820__register_nosave_regions(unsigned long limit_pfn) { - int i; + int idx; u64 last_addr =3D 0; =20 - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D &e820_table->entries[i]; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D &e820_table->entries[idx]; =20 if (entry->type !=3D E820_TYPE_RAM) continue; @@ -839,10 +839,10 @@ void __init e820__register_nosave_regions(unsigned lo= ng limit_pfn) */ static int __init e820__register_nvs_regions(void) { - int i; + int idx; =20 - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D &e820_table->entries[i]; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D &e820_table->entries[idx]; =20 if (entry->type =3D=3D E820_TYPE_NVS) acpi_nvs_register(entry->addr, entry->size); @@ -890,12 +890,12 @@ u64 __init e820__memblock_alloc_reserved(u64 size, u6= 4 align) */ static unsigned long __init e820__end_ram_pfn(unsigned long limit_pfn) { - int i; + int idx; unsigned long last_pfn =3D 0; unsigned long max_arch_pfn =3D MAX_ARCH_PFN; =20 - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D &e820_table->entries[i]; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D &e820_table->entries[idx]; unsigned long start_pfn; unsigned long end_pfn; =20 @@ -1145,7 +1145,7 @@ static bool __init e820_device_region(enum e820_type = type, struct resource *res) */ void __init e820__reserve_resources(void) { - int i; + int idx; struct resource *res; u64 end; =20 @@ -1153,8 +1153,8 @@ void __init e820__reserve_resources(void) SMP_CACHE_BYTES); e820_res =3D res; =20 - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D e820_table->entries + i; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D e820_table->entries + idx; =20 end =3D entry->addr + entry->size - 1; if (end !=3D (resource_size_t)end) { @@ -1180,8 +1180,8 @@ void __init e820__reserve_resources(void) } =20 /* Expose the kexec e820 table to sysfs: */ - for (i =3D 0; i < e820_table_kexec->nr_entries; i++) { - struct e820_entry *entry =3D e820_table_kexec->entries + i; + for (idx =3D 0; idx < e820_table_kexec->nr_entries; idx++) { + struct e820_entry *entry =3D e820_table_kexec->entries + idx; =20 firmware_map_add_early(entry->addr, entry->addr + entry->size, e820_type= _to_string(entry)); } @@ -1210,7 +1210,7 @@ static unsigned long __init ram_alignment(resource_si= ze_t pos) =20 void __init e820__reserve_resources_late(void) { - int i; + int idx; struct resource *res; =20 /* @@ -1218,7 +1218,7 @@ void __init e820__reserve_resources_late(void) * these can be claimed by device drivers later on: */ res =3D e820_res; - for (i =3D 0; i < e820_table->nr_entries; i++) { + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { if (!res->parent && res->end) insert_resource_expand_to_fit(&iomem_resource, res); res++; @@ -1236,8 +1236,8 @@ void __init e820__reserve_resources_late(void) * doesn't properly list 'stolen RAM' as a system region * in the E820 map. */ - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D &e820_table->entries[i]; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D &e820_table->entries[idx]; u64 start, end; =20 if (entry->type !=3D E820_TYPE_RAM) @@ -1314,7 +1314,7 @@ void __init e820__memory_setup(void) =20 void __init e820__memblock_setup(void) { - int i; + int idx; u64 end; =20 #ifdef CONFIG_MEMORY_HOTPLUG @@ -1358,8 +1358,8 @@ void __init e820__memblock_setup(void) */ memblock_allow_resize(); =20 - for (i =3D 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry =3D &e820_table->entries[i]; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + struct e820_entry *entry =3D &e820_table->entries[idx]; =20 end =3D entry->addr + entry->size; if (end !=3D (resource_size_t)end) --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 4B3861F3B98 for ; Mon, 21 Apr 2025 18:53:40 +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=1745261620; cv=none; b=FDabyhwKJLpVPzqnSzgbVF9SlZdf2C2vq4kHpJJFxdWl9/k3iLkJcpulHMaLG1bohgxxmkrDS3MCSw/XCMoBXVcWaorHgdtp8OL4wQuQQ4WBppzGTUdYUnNMTPGj5hyVe1oi7/Fy7xl1Hy7PN1Fcfv5KQb/ABHn5kwxFplruMGw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261620; c=relaxed/simple; bh=Byaj85c16GdgkFY1HUTUudSVyNy63/4LKMI9cvomcnQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PHr7P4HcDyi/lCMQsiIVOSZOC9gZ1ZhkMbivGFxqNkjCINo68J1xrgJDuu1iFvb1DfSPLGBgQfbCxlgeTinWky0jhLPiPMU+fUczRCLBU0sluRiZdIRNYxT+vMh9GtjKAvUcJazy07phWwrQ5WcbWsN7fjh4tEAw+KKjCn1I1Vs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HLyV6/Sh; 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="HLyV6/Sh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6C11C4CEEF; Mon, 21 Apr 2025 18:53:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261620; bh=Byaj85c16GdgkFY1HUTUudSVyNy63/4LKMI9cvomcnQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HLyV6/Shd3wIFtWqpxV2JSSeLwSdKCYXg29bpmWuHdMEm1hjVOhveF/1kT3J7ORHE IZ5qB12WyuF2bDeKlpejxhmnl4tbXJzbLemz7ef1CihQbeO774N108IgjW2JhdEfyl +dxGQhcDaK4RS8WAveavA54GAmLMA6OUzJVotvK3NHrcfVvZAfMVFFj63CkCaC0N1l 5hGPmvPBEh8Ad8bIr4a6hQn9xzHyWpLVhlAGBfnQQ61Mc+zo06ADnlFw2Ho59DBqO/ Km4JfLo2qQrBbFZM6MeLSq2dqGT4R3zkJLXJJJtkxwItsRp1PmNtfy1BMYHkHrcXxV bHF/ZSdJZnqYA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 18/29] x86/boot/e820: Change struct e820_table::nr_entries type from __u32 to u32 Date: Mon, 21 Apr 2025 20:51:58 +0200 Message-ID: <20250421185210.3372306-19-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" __u32 is for UAPI headers, and this definition is the only place in the kernel-internal E820 code that uses __u32. Change it to u32. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/include/asm/e820/types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/e820/types.h b/arch/x86/include/asm/e820/= types.h index 80c4a7266629..df12f7ee75d3 100644 --- a/arch/x86/include/asm/e820/types.h +++ b/arch/x86/include/asm/e820/types.h @@ -83,7 +83,7 @@ struct e820_entry { * The whole array of E820 entries: */ struct e820_table { - __u32 nr_entries; + u32 nr_entries; struct e820_entry entries[E820_MAX_ENTRIES]; }; =20 --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 825EB1EDA35 for ; Mon, 21 Apr 2025 18:53:43 +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=1745261624; cv=none; b=nZ/gm9mxDuL+rSveN493RWH63pZleYfjd4O5HO4v612Y8131ok4ED4JOwWkAYZ+TKkKiJUw1ClQ0ywvzTp7YNNksxusgRz2H0h91185fskNvU/NFfcGatu1JAuu4u3+8U7axbo/Uo8AR5Gp0OAtf5OY6woIIqGprFTHxILfr1N8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261624; c=relaxed/simple; bh=BuAjHqrV9gyzetitx3ZU9iVpXCqveD+trDE82sYlY50=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BD1IuujerBG1H3SoNyUps0HC6U0cyiFXV2Ll6CnVIl3TzpTgE4xTc+4uYNUgLBhD2EmywfGVGq/ZUazJOfIgQgWmqgDypVH4upCxtHMrO5QyRReMdfuo7vbjfPwmrq6BLQHVcHmBWm0AkznxFkwNxoGYPVnCJYZ6mw2HfQz1OZA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fcs+7xI3; 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="fcs+7xI3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8910AC4CEEB; Mon, 21 Apr 2025 18:53:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261623; bh=BuAjHqrV9gyzetitx3ZU9iVpXCqveD+trDE82sYlY50=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fcs+7xI3qDLJNf5jQNGQeF6Q2Yk04VCBbNlnaAEOGBu07Wkcd+MNYCHaUAZ5sFaUv s31y2Bel+s31xvT1DlQ1t5LStCo/fixEFUP0dWEBFmpa/9+VJe7oAPu+Np487PPAXG ZWkkHvjJ7W6sBCu8Rfcv4tgSuAuQHD91/PXxDYab8fxl3hkjYYQwqrFXugrIE4HA63 isiDpYrpe9rmpQBr0qmKPLA7ij713b1Fth8HF9YF15WBXKo/Z5kSRbQzfCK3uPVy2C 5YWAyeussZqYEKvsov9qCjL4rTxcHW7hHcRSyXmnCG7tSdEJ4gDz4qBkPkBO5fzugR gpWv3DIu/WgRQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 19/29] x86/boot/e820: Standardize e820 table index variable types under 'u32' Date: Mon, 21 Apr 2025 20:51:59 +0200 Message-ID: <20250421185210.3372306-20-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" So we have 'idx' types of 'int' and 'unsigned int', and sometimes we assign 'u32' fields such as e820_table::nr_entries to these 'int' values. While there's no real risk of overflow with these tables, make it all cleaner by standardizing on a single type: u32. This also happens to shrink the code a bit: text data bss dec hex filename 7745 44072 0 51817 ca69 e820.o.before 7613 44072 0 51685 c9e5 e820.o.after Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 919950d0f03d..d55cb77537e7 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -75,7 +75,7 @@ EXPORT_SYMBOL(pci_mem_start); static bool _e820__mapped_any(struct e820_table *table, u64 start, u64 end, enum e820_type type) { - int idx; + u32 idx; =20 for (idx =3D 0; idx < table->nr_entries; idx++) { struct e820_entry *entry =3D &table->entries[idx]; @@ -110,7 +110,7 @@ EXPORT_SYMBOL_GPL(e820__mapped_any); static struct e820_entry *__e820__mapped_all(u64 start, u64 end, enum e820_type type) { - int idx; + u32 idx; =20 for (idx =3D 0; idx < e820_table->nr_entries; idx++) { struct e820_entry *entry =3D &e820_table->entries[idx]; @@ -163,7 +163,7 @@ int e820__get_entry_type(u64 start, u64 end) */ static void __init __e820__range_add(struct e820_table *table, u64 start, = u64 size, enum e820_type type) { - int idx =3D table->nr_entries; + u32 idx =3D table->nr_entries; =20 if (idx >=3D ARRAY_SIZE(table->entries)) { pr_err("too many E820 table entries; ignoring [mem %#010llx-%#010llx]\n", @@ -236,7 +236,7 @@ static void e820_print_size(u64 size) static void __init e820__print_table(const char *who) { u64 range_end_prev =3D 0; - int idx; + u32 idx; =20 for (idx =3D 0; idx < e820_table->nr_entries; idx++) { struct e820_entry *entry =3D e820_table->entries + idx; @@ -524,7 +524,7 @@ static u64 __init __e820__range_update(struct e820_table *table, u64 start, u64 size, enum e= 820_type old_type, enum e820_type new_type) { u64 end; - unsigned int idx; + u32 idx; u64 real_updated_size =3D 0; =20 BUG_ON(old_type =3D=3D new_type); @@ -602,7 +602,7 @@ u64 __init e820__range_update_table(struct e820_table *= t, u64 start, u64 size, /* Remove a range of memory from the E820 table: */ u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type= , bool check_type) { - int idx; + u32 idx; u64 end; u64 real_removed_size =3D 0; =20 @@ -814,7 +814,7 @@ void __init e820__memory_setup_extended(u64 phys_addr, = u32 data_len) */ void __init e820__register_nosave_regions(unsigned long limit_pfn) { - int idx; + u32 idx; u64 last_addr =3D 0; =20 for (idx =3D 0; idx < e820_table->nr_entries; idx++) { @@ -839,7 +839,7 @@ void __init e820__register_nosave_regions(unsigned long= limit_pfn) */ static int __init e820__register_nvs_regions(void) { - int idx; + u32 idx; =20 for (idx =3D 0; idx < e820_table->nr_entries; idx++) { struct e820_entry *entry =3D &e820_table->entries[idx]; @@ -890,7 +890,7 @@ u64 __init e820__memblock_alloc_reserved(u64 size, u64 = align) */ static unsigned long __init e820__end_ram_pfn(unsigned long limit_pfn) { - int idx; + u32 idx; unsigned long last_pfn =3D 0; unsigned long max_arch_pfn =3D MAX_ARCH_PFN; =20 @@ -1145,7 +1145,7 @@ static bool __init e820_device_region(enum e820_type = type, struct resource *res) */ void __init e820__reserve_resources(void) { - int idx; + u32 idx; struct resource *res; u64 end; =20 @@ -1210,7 +1210,7 @@ static unsigned long __init ram_alignment(resource_si= ze_t pos) =20 void __init e820__reserve_resources_late(void) { - int idx; + u32 idx; struct resource *res; =20 /* @@ -1314,7 +1314,7 @@ void __init e820__memory_setup(void) =20 void __init e820__memblock_setup(void) { - int idx; + u32 idx; u64 end; =20 #ifdef CONFIG_MEMORY_HOTPLUG --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 E0AF61F4C8F for ; Mon, 21 Apr 2025 18:53:45 +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=1745261626; cv=none; b=eC/kWycXx0cEgool3b189qeZ02MpotHallW5WV8gVKkoHIgoJRAacjMDcR+yKRrff3UhV/u2vwJsNARdfHBFWL5v9/40THq7Z8/zRB0gR4NGjQ1XdpqcdO+JOIn0lv1X/ukmFfnyZ6ogwxy2B7zsK2978ZG83si4KynsAkKN0E4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261626; c=relaxed/simple; bh=POZR5KKXS438W5+E+m5kr9lScH+4LzjpbBPckh8oO40=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZaGvokQhcJKMPI9pYDbQWFunoBc7t9fiASL0M+s++aG3xNDl8o8yRJmX+PhFfd0B+17l6G3tUp8JjglAA0iz+MBYTT/EZ6gGAlkXGrk2ui2QycWRw6apcT1JoDqsFfFewpiGG0qSqjm4IOQtG8ui+KdSKQSlm1HOmMhZ5sFMBn4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MwQW6ivn; 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="MwQW6ivn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C9FEC4CEEC; Mon, 21 Apr 2025 18:53:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261625; bh=POZR5KKXS438W5+E+m5kr9lScH+4LzjpbBPckh8oO40=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MwQW6ivn/i8v4rgXqDPnOIcd+7aMbdlOaHsB/Aj0evWu7+0IqWdsPoP69DRJZHSwM 3BNkC3le4RXlYickYeYcUyQaTBYjaF6epolNir0j9XQ7PA93vpzRywMNIXwWweegJT bbsBRFrajlmY4fNW1JoD0Ii5furwTJeIwE1d35mWcXFnNq+hEkxgDweyQ/o3ZJnGfs ZdACebbsknjxHQcpvb3pDZ1lsJ+nw6gznkt31PyYQGVyPHGdCN2VpJdO/9epoIhfMu FsIgQG3B/wzEBCaeJpNOWAxy8NUbFybDoUhmllVMX8QXPOgNgp/SG0io2lRG5KIYj8 FeXRI1eLkQgzg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 20/29] x86/boot/e820: Clean up e820__setup_pci_gap()/e820_search_gap() a bit Date: Mon, 21 Apr 2025 20:52:00 +0200 Message-ID: <20250421185210.3372306-21-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use a bit more readable variable names, we haven't run out of underscore characters in the kernel yet. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index d55cb77537e7..01d50331856c 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -680,7 +680,7 @@ static void __init e820__update_table_kexec(void) /* * Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB). */ -static int __init e820_search_gap(unsigned long *gapstart, unsigned long *= gapsize) +static int __init e820_search_gap(unsigned long *gap_start, unsigned long = *gap_size) { u64 last =3D MAX_GAP_END; int idx =3D e820_table->nr_entries; @@ -697,9 +697,9 @@ static int __init e820_search_gap(unsigned long *gapsta= rt, unsigned long *gapsiz if (last > end) { unsigned long gap =3D last - end; =20 - if (gap >=3D *gapsize) { - *gapsize =3D gap; - *gapstart =3D end; + if (gap >=3D *gap_size) { + *gap_size =3D gap; + *gap_start =3D end; found =3D 1; } } @@ -719,29 +719,29 @@ static int __init e820_search_gap(unsigned long *gaps= tart, unsigned long *gapsiz */ __init void e820__setup_pci_gap(void) { - unsigned long gapstart, gapsize; + unsigned long gap_start, gap_size; int found; =20 - gapsize =3D 0x400000; - found =3D e820_search_gap(&gapstart, &gapsize); + gap_size =3D 0x400000; + found =3D e820_search_gap(&gap_start, &gap_size); =20 if (!found) { #ifdef CONFIG_X86_64 - gapstart =3D (max_pfn << PAGE_SHIFT) + 1024*1024; + gap_start =3D (max_pfn << PAGE_SHIFT) + 1024*1024; pr_err("Cannot find an available gap in the 32-bit address range\n"); pr_err("PCI devices with unassigned 32-bit BARs may not work!\n"); #else - gapstart =3D 0x10000000; + gap_start =3D 0x10000000; #endif } =20 /* * e820__reserve_resources_late() protects stolen RAM already: */ - pci_mem_start =3D gapstart; + pci_mem_start =3D gap_start; =20 pr_info("[gap %#010lx-%#010lx] available for PCI devices\n", - gapstart, gapstart + gapsize - 1); + gap_start, gap_start + gap_size - 1); } =20 /* --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 1A02C1F4CA9 for ; Mon, 21 Apr 2025 18:53:48 +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=1745261629; cv=none; b=IaIgkR0pM0ctG7ZJP39Kz1TTSMTr9/Jqmqis9TY3gh+gG0cEun8PxNV7e1gHX9o3kMiFWsrG5WGM8cga1Yn4nkA1XBcpezKA+I/5SNnWri1JBY1y6K2hnKqhL3LTBDgk80u36AB/kbI3+Q/bKeVY23l3HqHcWnjFHJCvbKZstwY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261629; c=relaxed/simple; bh=8KHJkVov36KW/o3haD+BpmraKNKIgEBevaVz3JzNsZY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u+6qEu3vY3ozOd+iM1FQDERDc39ICWk99xaRrNNorGmPkUIRk399F/JV3hYb/+GKM72uOxmDPiy5yHzz6aMEwIrfc5up4nPJqvmpnYm2/iRHLralPX/sCa3StlLdeUWKSBUSov/P7BSdVW1RaBahkesXj33vgyHZla5ABfVwTtY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CyVeVm89; 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="CyVeVm89" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E99FC4CEEB; Mon, 21 Apr 2025 18:53:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261628; bh=8KHJkVov36KW/o3haD+BpmraKNKIgEBevaVz3JzNsZY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CyVeVm89vtt2vxBvqdr6vRwqWpzFWsY2eoZ77GmD/lH/tbz4srRxc09910xES7oAV avq+U8sKTd139xBesB+ZiAnXzktLA/833lrfGeeuw/ZGg9ZRhT9JbApTiy/EvY9+nN ESsi9BYDrpKfYYMUUbQofrRS3/e/xC0WMGzfl0qPzEPuNBTc9BhCZwjOuJo2N00YuM bIzY5wozHzOkAxT4gQXU2ChP/YNDxOhHLR4+aml2YktYomDvO1F+6/KYer2Fzcvv3a 46bBJWHfVrlq2vnPa6XwXFhqMRZEZa3QCZSSez+rlf9YFQgWY+En2G+ddv7+JgHUeJ 4T8qA3bT5TamA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 21/29] x86/boot/e820: Change e820_search_gap() to search for the highest-address PCI gap Date: Mon, 21 Apr 2025 20:52:01 +0200 Message-ID: <20250421185210.3372306-22-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Right now the main x86 function that determines the position and size of the 'PCI gap', e820_search_gap(), has this curious property: while (--idx >=3D 0) { ... if (gap >=3D *gap_size) { I.e. it will iterate the E820 table backwards, from its end to the beginnin= g, and will search for larger and larger gaps in the memory map below 4GB, until it finishes with the table. This logic will, should there be two gaps with the same size, pick the one with the lower physical address - which is contrary to usual practice that the PCI gap is just below 4GB. Furthermore, the commit that introduced this weird logic 16 years ago: 3381959da5a0 ("x86: cleanup e820_setup_gap(), add e820_search_gap(), v2") - if (gap > gapsize) { + if (gap >=3D *gapsize) { didn't even declare this change, the title says it's a cleanup, and the changelog declares it as a preparatory refactoring for a later bugfix: 809d9a8f93bd ("x86/PCI: ACPI based PCI gap calculation") which bugfix was reverted only 1 day later without much of an explanation, and was never reintroduced: 58b6e5538460 ("Revert "x86/PCI: ACPI based PCI gap calculation"") So based on the Git archeology and by the plain reading of the code I declare this '>=3D' change an unintended bug and side effect. Change it to '>' again. It should not make much of a difference in practice, as the likelihood of having *two* largest gaps with exactly the same size are very low outside of weird user-provided memory maps. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 01d50331856c..24b2e8a93853 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -697,7 +697,7 @@ static int __init e820_search_gap(unsigned long *gap_st= art, unsigned long *gap_s if (last > end) { unsigned long gap =3D last - end; =20 - if (gap >=3D *gap_size) { + if (gap > *gap_size) { *gap_size =3D gap; *gap_start =3D end; found =3D 1; --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 F3D9D1EE7B6 for ; Mon, 21 Apr 2025 18:53:51 +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=1745261632; cv=none; b=bGrFFPL5xMFIv+xr9r8ljDfcON1LDxxQ/fj59tgjTL6or38KQIiW8c5DA53HAx+L/tuFZ3JEmKHeDIP0YJPWz01x9eDePwULSNKg867aD7kn/gQpYYpK93Sws1Oc7QSEOaotVsDli05dQj08bpg2DjMSHTSH+Hb5kiznp/21q08= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261632; c=relaxed/simple; bh=+W2xcK4KRppKgZobQ6197LwwjgbCSohCG6OneLrFvBg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ewsykacwAbC7VhgEPw7yx2KmH6by8AcMyXREyoLnho/PRYcQsoLzSRcxdphoXwbnQEajD3XTu1uLjQeAdqPW7NQ07b8y6hbumtAsRiIx0s5Lp6yLiEszxb6LTtCqsie0ViS6onMuV8OYH6kl913UqhPFwEHfx0XDyCcijXjUalw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZW6j092e; 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="ZW6j092e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 037F2C4CEEC; Mon, 21 Apr 2025 18:53:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261631; bh=+W2xcK4KRppKgZobQ6197LwwjgbCSohCG6OneLrFvBg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZW6j092ecUjNK8cF5IYnvN1E1awBi0ymcmxTX3D47+cTVSRvmR6G7nQEejWDKICeT SOytESFySz+QE4EIjjhxbV3Mj88Crjz1GG5QCz5lQ+WD98ca3XMEGwZ2TqfKijezpB oDosCbN1qDMnSOV4zN6GuMiuC4UqrwKt+U936zIB6c9BujEI+iggq3NlywjxUdk9wG f45k9joBowS6oL8zO4r/phDl/fdyCACco8dUOHcTe1KiUgNXnm8bFcmFtwBbGILgWW 0BkA4FtCORvWlj3Wu2STyvYvmnIAqiz1Kss+zbxkSRxWNarmUhvEuoRSxIMX2REZvI NrpPienY9q25g== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 22/29] x86/boot/e820: Rename gap_start/gap_size to max_gap_start/max_gap_start in e820_search_gap() et al Date: Mon, 21 Apr 2025 20:52:02 +0200 Message-ID: <20250421185210.3372306-23-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The PCI gap searching functions pass around pointers to the gap_start/gap_size variables, which refer to the maximum size gap found so far. Rename the variables to say so, and disambiguate their namespace from 'current gap' variables. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 24b2e8a93853..d0f9c544a14c 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -680,7 +680,7 @@ static void __init e820__update_table_kexec(void) /* * Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB). */ -static int __init e820_search_gap(unsigned long *gap_start, unsigned long = *gap_size) +static int __init e820_search_gap(unsigned long *max_gap_start, unsigned l= ong *max_gap_size) { u64 last =3D MAX_GAP_END; int idx =3D e820_table->nr_entries; @@ -697,9 +697,9 @@ static int __init e820_search_gap(unsigned long *gap_st= art, unsigned long *gap_s if (last > end) { unsigned long gap =3D last - end; =20 - if (gap > *gap_size) { - *gap_size =3D gap; - *gap_start =3D end; + if (gap > *max_gap_size) { + *max_gap_size =3D gap; + *max_gap_start =3D end; found =3D 1; } } @@ -719,29 +719,29 @@ static int __init e820_search_gap(unsigned long *gap_= start, unsigned long *gap_s */ __init void e820__setup_pci_gap(void) { - unsigned long gap_start, gap_size; + unsigned long max_gap_start, max_gap_size; int found; =20 - gap_size =3D 0x400000; - found =3D e820_search_gap(&gap_start, &gap_size); + max_gap_size =3D 0x400000; + found =3D e820_search_gap(&max_gap_start, &max_gap_size); =20 if (!found) { #ifdef CONFIG_X86_64 - gap_start =3D (max_pfn << PAGE_SHIFT) + 1024*1024; + max_gap_start =3D (max_pfn << PAGE_SHIFT) + 1024*1024; pr_err("Cannot find an available gap in the 32-bit address range\n"); pr_err("PCI devices with unassigned 32-bit BARs may not work!\n"); #else - gap_start =3D 0x10000000; + max_gap_start =3D 0x10000000; #endif } =20 /* * e820__reserve_resources_late() protects stolen RAM already: */ - pci_mem_start =3D gap_start; + pci_mem_start =3D max_gap_start; =20 pr_info("[gap %#010lx-%#010lx] available for PCI devices\n", - gap_start, gap_start + gap_size - 1); + max_gap_start, max_gap_start + max_gap_size - 1); } =20 /* --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 5CC9A1F8743 for ; Mon, 21 Apr 2025 18:53:54 +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=1745261634; cv=none; b=IHpKvZdraRxEi0blihenhZ+YJ22FiwpumtolT0bmBylWq4NzpZd0ncvZKZs8pjKCezr82ICtdQ0zIR7rnWYntgzky6XHFJNHSQH6MFXqg4LNWG4S8w2O8M7rs7uvt2o1epWJTlm7cIdWxym39Va0BAxoD2R2hg0f3vt3C+FfMxg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261634; c=relaxed/simple; bh=B8HMP545YkJOzLe4wuG1fHgGabFH4VxeskR4IeYCpYA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V/AAdVNyPKJN7ODpRHPC6Oknr0urucjeQgFylb1NS70QltomydzVxrggmX9W9whgdMsNzFs0gJrh2/8J+vdAK7CwnOw5pVWC3jV3T7CIgqIcWK+U9e33CVWZ+BzByQkV80N9mQh9m1bDhc9PGN/F0VR/03b5OkrJfc/YB3Kg13c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a6+7ZpVA; 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="a6+7ZpVA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9D75C4CEEA; Mon, 21 Apr 2025 18:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261634; bh=B8HMP545YkJOzLe4wuG1fHgGabFH4VxeskR4IeYCpYA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a6+7ZpVAAOMZRFWAhK31lw020B3qDg673F6xVlarCmQUv89TTG0nIkIXEay7VA3dT q+2caj8QrcbQ+mceatw0nWbbKnNBrmdKN6syBKKhh44eiIv9hUbbdi2ZnqvMsVhPcf MTimibYynBrB0cWpOa938Pe7vhp1XB1lKFSqywwhvp2aS4rH/k6TtPbpnKSGna+3uE BY/zfM+0d/Lo4Ht2P3IyrKLarYDZPjt3QGNWW/IeYCpjGetdaeHuAohl3tezKQSV2N 8+jzV3YnWGDmCKcRtvEhPQCBNR3wMM1b3JC1k233or1D11LMEvYE3Lq3eSkqKAzG6K d4XBttcZDtM7g== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 23/29] x86/boot/e820: Simplify & clarify __e820__range_add() a bit Date: Mon, 21 Apr 2025 20:52:03 +0200 Message-ID: <20250421185210.3372306-24-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use 'entry_new' to make clear we are allocating a new entry. Change the table-full message to say that the table is full. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index d0f9c544a14c..e5a50aadc631 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -164,16 +164,19 @@ int e820__get_entry_type(u64 start, u64 end) static void __init __e820__range_add(struct e820_table *table, u64 start, = u64 size, enum e820_type type) { u32 idx =3D table->nr_entries; + struct e820_entry *entry_new; =20 if (idx >=3D ARRAY_SIZE(table->entries)) { - pr_err("too many E820 table entries; ignoring [mem %#010llx-%#010llx]\n", + pr_err("E820 table full; ignoring [mem %#010llx-%#010llx]\n", start, start + size-1); return; } =20 - table->entries[idx].addr =3D start; - table->entries[idx].size =3D size; - table->entries[idx].type =3D type; + entry_new =3D table->entries + idx; + + entry_new->addr =3D start; + entry_new->size =3D size; + entry_new->type =3D type; =20 table->nr_entries++; } --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 A26931EB1AF for ; Mon, 21 Apr 2025 18:53:57 +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=1745261637; cv=none; b=sqQ7/zzHD0ZKNienFqpThGjVD7ftclK5umXZaGhNkkpY+C2LZGIa85Lx3qu/hu4bEHyoUKp2Fjkfyep87Y68pC4weUxv6A6jffdu2Qt4UQB27RQqXdW+072XVWXBUuf+QF96Xowfr5xr9QQfvrzQyp4LqFguhhuibu/YG9PaO2k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261637; c=relaxed/simple; bh=rueChAMEpj0WRxAfWvuXRUtYV1WTXlGvDlNgxa//gCw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VOKxEcobftFwXsy22TTuJ2n1LD+AeIFX2pzI13olUwjz8wYbnbsb33MQCiuTkktmR+uG+ZZsjgwfL1h33A+bde2JL0XqphX4xXaQipwd736431ac/rmeCQlNjvLxV3SD5z1capTg+rpLYSV2gF+c1wPCCY7t+j8PwXKjkcupGpc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t+T/BFBK; 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="t+T/BFBK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E1D9C4CEEF; Mon, 21 Apr 2025 18:53:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261637; bh=rueChAMEpj0WRxAfWvuXRUtYV1WTXlGvDlNgxa//gCw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t+T/BFBKciHZ0jL7P06iNwrXUmzrBFZXaWieOZC6hNMsf2VTmnhl6u6mns91dsFWp G5VFkZ1NoF0117E+nFoTYpi+W8LhBxOZVI71VzGNVkryp2Y/0MQpGBLWxW3bwOtOrb UQdSe1UT0cO98SZK0MgoD3AOs/PHe9mrnSJu7mhBvMtyt6tv1vtgQOxXjU+bZD7g/0 Rl/TstyJinq18F//6PgJ1aogk1fmD/MLa7RrYr/n4C7TVV3hWmkpTVpJjUvknRAHI7 mzc86RFf7pxclo/o9r+oGPWC86P5FXtto8FfeAl/GfRdQXQUm/Tn8rB8g19jMsMIiS A6Plz7qK6tlgQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 24/29] x86/boot/e820: Standardize __init/__initdata tag placement Date: Mon, 21 Apr 2025 20:52:04 +0200 Message-ID: <20250421185210.3372306-25-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" So the e820.c file has a hodgepodge of __init and __initdata tag placements: static int __init e820_search_gap(unsigned long *max_gap_start, unsigne= d long *max_gap_size) __init void e820__setup_pci_gap(void) __init void e820__reallocate_tables(void) void __init e820__memory_setup_extended(u64 phys_addr, u32 data_len) void __init e820__register_nosave_regions(unsigned long limit_pfn) static int __init e820__register_nvs_regions(void) u64 __init e820__memblock_alloc_reserved(u64 size, u64 align) Standardize on the style used by e820__setup_pci_gap() and place them before the storage class. In addition to the consistency, as a bonus this makes the grep output rather clean looking: __init void e820__range_remove(u64 start, u64 size, enum e820_type filt= er_type) __init void e820__update_table_print(void) __init static void e820__update_table_kexec(void) __init static int e820_search_gap(unsigned long *max_gap_start, unsigne= d long *max_gap_size) __init void e820__setup_pci_gap(void) __init void e820__reallocate_tables(void) __init void e820__memory_setup_extended(u64 phys_addr, u32 data_len) __init void e820__register_nosave_regions(unsigned long limit_pfn) __init static int e820__register_nvs_regions(void) ... and if one learns to just ignore the leftmost '__init' noise then the rest of the line looks just like a regular C function definition. With the 'mixed' tag placement style the __init tag breaks up the function's prototype for no good reason. Do the same for __initdata. Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 92 +++++++++++++++++++++++++---------------------= ---- 1 file changed, 46 insertions(+), 46 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index e5a50aadc631..ec5628a844dc 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -54,9 +54,9 @@ * re-propagated. So its main role is a temporary bootstrap storage of fir= mware * specific memory layout data during early bootup. */ -static struct e820_table e820_table_init __initdata; -static struct e820_table e820_table_kexec_init __initdata; -static struct e820_table e820_table_firmware_init __initdata; +__initdata static struct e820_table e820_table_init; +__initdata static struct e820_table e820_table_kexec_init; +__initdata static struct e820_table e820_table_firmware_init; =20 __refdata struct e820_table *e820_table =3D &e820_table_init; __refdata struct e820_table *e820_table_kexec =3D &e820_table_kexec_init; @@ -143,7 +143,7 @@ static struct e820_entry *__e820__mapped_all(u64 start,= u64 end, /* * This function checks if the entire range is mapped with typ= e. */ -bool __init e820__mapped_all(u64 start, u64 end, enum e820_type type) +__init bool e820__mapped_all(u64 start, u64 end, enum e820_type type) { return __e820__mapped_all(start, end, type); } @@ -161,7 +161,7 @@ int e820__get_entry_type(u64 start, u64 end) /* * Add a memory region to the kernel E820 map. */ -static void __init __e820__range_add(struct e820_table *table, u64 start, = u64 size, enum e820_type type) +__init static void __e820__range_add(struct e820_table *table, u64 start, = u64 size, enum e820_type type) { u32 idx =3D table->nr_entries; struct e820_entry *entry_new; @@ -181,12 +181,12 @@ static void __init __e820__range_add(struct e820_tabl= e *table, u64 start, u64 si table->nr_entries++; } =20 -void __init e820__range_add(u64 start, u64 size, enum e820_type type) +__init void e820__range_add(u64 start, u64 size, enum e820_type type) { __e820__range_add(e820_table, start, size, type); } =20 -static void __init e820_print_type(enum e820_type type) +__init static void e820_print_type(enum e820_type type) { switch (type) { case E820_TYPE_RAM: pr_cont(" kernel usable RAM"); break; @@ -236,7 +236,7 @@ static void e820_print_size(u64 size) pr_cont(" %4llu TB", size/SZ_1T); } =20 -static void __init e820__print_table(const char *who) +__init static void e820__print_table(const char *who) { u64 range_end_prev =3D 0; u32 idx; @@ -343,12 +343,12 @@ struct change_member { u64 addr; }; =20 -static struct change_member change_point_list[2*E820_MAX_ENTRIES] __initda= ta; -static struct change_member *change_point[2*E820_MAX_ENTRIES] __initdata; -static struct e820_entry *overlap_list[E820_MAX_ENTRIES] __initdata; -static struct e820_entry new_entries[E820_MAX_ENTRIES] __initdata; +__initdata static struct change_member change_point_list[2*E820_MAX_ENTRIE= S]; +__initdata static struct change_member *change_point[2*E820_MAX_ENTRIES]; +__initdata static struct e820_entry *overlap_list[E820_MAX_ENTRIES]; +__initdata static struct e820_entry new_entries[E820_MAX_ENTRIES]; =20 -static int __init cpcompare(const void *a, const void *b) +__init static int cpcompare(const void *a, const void *b) { struct change_member * const *app =3D a, * const *bpp =3D b; const struct change_member *ap =3D *app, *bp =3D *bpp; @@ -383,7 +383,7 @@ static bool e820_type_mergeable(enum e820_type type) return true; } =20 -int __init e820__update_table(struct e820_table *table) +__init int e820__update_table(struct e820_table *table) { struct e820_entry *entries =3D table->entries; u32 max_nr_entries =3D ARRAY_SIZE(table->entries); @@ -483,7 +483,7 @@ int __init e820__update_table(struct e820_table *table) return 0; } =20 -static int __init __append_e820_table(struct boot_e820_entry *entries, u32= nr_entries) +__init static int __append_e820_table(struct boot_e820_entry *entries, u32= nr_entries) { struct boot_e820_entry *entry =3D entries; =20 @@ -514,7 +514,7 @@ static int __init __append_e820_table(struct boot_e820_= entry *entries, u32 nr_en * will have given us a memory map that we can use to properly * set up memory. If we aren't, we'll fake a memory map. */ -static int __init append_e820_table(struct boot_e820_entry *entries, u32 n= r_entries) +__init static int append_e820_table(struct boot_e820_entry *entries, u32 n= r_entries) { /* Only one memory region (or negative)? Ignore it */ if (nr_entries < 2) @@ -523,7 +523,7 @@ static int __init append_e820_table(struct boot_e820_en= try *entries, u32 nr_entr return __append_e820_table(entries, nr_entries); } =20 -static u64 __init +__init static u64 __e820__range_update(struct e820_table *table, u64 start, u64 size, enum e= 820_type old_type, enum e820_type new_type) { u64 end; @@ -591,19 +591,19 @@ __e820__range_update(struct e820_table *table, u64 st= art, u64 size, enum e820_ty return real_updated_size; } =20 -u64 __init e820__range_update(u64 start, u64 size, enum e820_type old_type= , enum e820_type new_type) +__init u64 e820__range_update(u64 start, u64 size, enum e820_type old_type= , enum e820_type new_type) { return __e820__range_update(e820_table, start, size, old_type, new_type); } =20 -u64 __init e820__range_update_table(struct e820_table *t, u64 start, u64 s= ize, +__init u64 e820__range_update_table(struct e820_table *t, u64 start, u64 s= ize, enum e820_type old_type, enum e820_type new_type) { return __e820__range_update(t, start, size, old_type, new_type); } =20 /* Remove a range of memory from the E820 table: */ -u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type= , bool check_type) +__init u64 e820__range_remove(u64 start, u64 size, enum e820_type old_type= , bool check_type) { u32 idx; u64 end; @@ -664,7 +664,7 @@ u64 __init e820__range_remove(u64 start, u64 size, enum= e820_type old_type, bool return real_removed_size; } =20 -void __init e820__update_table_print(void) +__init void e820__update_table_print(void) { if (e820__update_table(e820_table)) return; @@ -673,7 +673,7 @@ void __init e820__update_table_print(void) e820__print_table("modified"); } =20 -static void __init e820__update_table_kexec(void) +__init static void e820__update_table_kexec(void) { e820__update_table(e820_table_kexec); } @@ -683,7 +683,7 @@ static void __init e820__update_table_kexec(void) /* * Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB). */ -static int __init e820_search_gap(unsigned long *max_gap_start, unsigned l= ong *max_gap_size) +__init static int e820_search_gap(unsigned long *max_gap_start, unsigned l= ong *max_gap_size) { u64 last =3D MAX_GAP_END; int idx =3D e820_table->nr_entries; @@ -786,7 +786,7 @@ __init void e820__reallocate_tables(void) * the remaining (if any) entries are passed via the SETUP_E820_EXT node of * struct setup_data, which is parsed here. */ -void __init e820__memory_setup_extended(u64 phys_addr, u32 data_len) +__init void e820__memory_setup_extended(u64 phys_addr, u32 data_len) { int entries; struct boot_e820_entry *extmap; @@ -815,7 +815,7 @@ void __init e820__memory_setup_extended(u64 phys_addr, = u32 data_len) * This function requires the E820 map to be sorted and without any * overlapping entries. */ -void __init e820__register_nosave_regions(unsigned long limit_pfn) +__init void e820__register_nosave_regions(unsigned long limit_pfn) { u32 idx; u64 last_addr =3D 0; @@ -840,7 +840,7 @@ void __init e820__register_nosave_regions(unsigned long= limit_pfn) * Register ACPI NVS memory regions, so that we can save/restore them duri= ng * hibernation and the subsequent resume: */ -static int __init e820__register_nvs_regions(void) +__init static int e820__register_nvs_regions(void) { u32 idx; =20 @@ -864,7 +864,7 @@ core_initcall(e820__register_nvs_regions); * This allows kexec to fake a new mptable, as if it came from the real * system. */ -u64 __init e820__memblock_alloc_reserved(u64 size, u64 align) +__init u64 e820__memblock_alloc_reserved(u64 size, u64 align) { u64 addr; =20 @@ -891,7 +891,7 @@ u64 __init e820__memblock_alloc_reserved(u64 size, u64 = align) /* * Find the highest page frame number we have available */ -static unsigned long __init e820__end_ram_pfn(unsigned long limit_pfn) +__init static unsigned long e820__end_ram_pfn(unsigned long limit_pfn) { u32 idx; unsigned long last_pfn =3D 0; @@ -927,20 +927,20 @@ static unsigned long __init e820__end_ram_pfn(unsigne= d long limit_pfn) return last_pfn; } =20 -unsigned long __init e820__end_of_ram_pfn(void) +__init unsigned long e820__end_of_ram_pfn(void) { return e820__end_ram_pfn(MAX_ARCH_PFN); } =20 -unsigned long __init e820__end_of_low_ram_pfn(void) +__init unsigned long e820__end_of_low_ram_pfn(void) { return e820__end_ram_pfn(1UL << (32 - PAGE_SHIFT)); } =20 -static int userdef __initdata; +__initdata static int userdef; =20 /* The "mem=3Dnopentium" boot option disables 4MB page tables on 32-bit ke= rnels: */ -static int __init parse_memopt(char *p) +__init static int parse_memopt(char *p) { u64 mem_size; =20 @@ -974,7 +974,7 @@ static int __init parse_memopt(char *p) } early_param("mem", parse_memopt); =20 -static int __init parse_memmap_one(char *p) +__init static int parse_memmap_one(char *p) { char *oldp; u64 start_at, mem_size; @@ -1031,7 +1031,7 @@ static int __init parse_memmap_one(char *p) return *p =3D=3D '\0' ? 0 : -EINVAL; } =20 -static int __init parse_memmap_opt(char *str) +__init static int parse_memmap_opt(char *str) { while (str) { char *k =3D strchr(str, ','); @@ -1052,7 +1052,7 @@ early_param("memmap", parse_memmap_opt); * have been processed, in which case we already have an E820 table filled= in * via the parameter callback function(s), but it's not sorted and printed= yet: */ -void __init e820__finish_early_params(void) +__init void e820__finish_early_params(void) { if (userdef) { if (e820__update_table(e820_table) < 0) @@ -1063,7 +1063,7 @@ void __init e820__finish_early_params(void) } } =20 -static const char *__init e820_type_to_string(struct e820_entry *entry) +__init static const char * e820_type_to_string(struct e820_entry *entry) { switch (entry->type) { case E820_TYPE_RAM: return "System RAM"; @@ -1078,7 +1078,7 @@ static const char *__init e820_type_to_string(struct = e820_entry *entry) } } =20 -static unsigned long __init e820_type_to_iomem_type(struct e820_entry *ent= ry) +__init static unsigned long e820_type_to_iomem_type(struct e820_entry *ent= ry) { switch (entry->type) { case E820_TYPE_RAM: return IORESOURCE_SYSTEM_RAM; @@ -1093,7 +1093,7 @@ static unsigned long __init e820_type_to_iomem_type(s= truct e820_entry *entry) } } =20 -static unsigned long __init e820_type_to_iores_desc(struct e820_entry *ent= ry) +__init static unsigned long e820_type_to_iores_desc(struct e820_entry *ent= ry) { switch (entry->type) { case E820_TYPE_ACPI: return IORES_DESC_ACPI_TABLES; @@ -1111,13 +1111,13 @@ static unsigned long __init e820_type_to_iores_desc= (struct e820_entry *entry) /* * We assign one resource entry for each E820 map entry: */ -static struct resource __initdata *e820_res; +__initdata static struct resource *e820_res; =20 /* * Is this a device address region that should not be marked busy? * (Versus system address regions that we register & lock early.) */ -static bool __init e820_device_region(enum e820_type type, struct resource= *res) +__init static bool e820_device_region(enum e820_type type, struct resource= *res) { /* This is the legacy BIOS/DOS ROM-shadow + MMIO region: */ if (res->start < (1ULL<<20)) @@ -1146,7 +1146,7 @@ static bool __init e820_device_region(enum e820_type = type, struct resource *res) /* * Mark E820 system regions as busy for the resource manager: */ -void __init e820__reserve_resources(void) +__init void e820__reserve_resources(void) { u32 idx; struct resource *res; @@ -1193,7 +1193,7 @@ void __init e820__reserve_resources(void) /* * How much should we pad the end of RAM, depending on where it is? */ -static unsigned long __init ram_alignment(resource_size_t pos) +__init static unsigned long ram_alignment(resource_size_t pos) { unsigned long mb =3D pos >> 20; =20 @@ -1211,7 +1211,7 @@ static unsigned long __init ram_alignment(resource_si= ze_t pos) =20 #define MAX_RESOURCE_SIZE ((resource_size_t)-1) =20 -void __init e820__reserve_resources_late(void) +__init void e820__reserve_resources_late(void) { u32 idx; struct resource *res; @@ -1261,7 +1261,7 @@ void __init e820__reserve_resources_late(void) /* * Pass the firmware (bootloader) E820 map to the kernel and process it: */ -char *__init e820__memory_setup_default(void) +__init char * e820__memory_setup_default(void) { char *who =3D "BIOS-e820"; =20 @@ -1299,7 +1299,7 @@ char *__init e820__memory_setup_default(void) * E820 map - with an optional platform quirk available for virtual platfo= rms * to override this method of boot environment processing: */ -void __init e820__memory_setup(void) +__init void e820__memory_setup(void) { char *who; =20 @@ -1315,7 +1315,7 @@ void __init e820__memory_setup(void) e820__print_table(who); } =20 -void __init e820__memblock_setup(void) +__init void e820__memblock_setup(void) { u32 idx; u64 end; --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 6CDF61FAC48 for ; Mon, 21 Apr 2025 18:54:00 +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=1745261640; cv=none; b=BR+39Ti9GOdyKVEUlvbY9ZTLzE9whSRgoVYSc+K8WOOqW2B381uNCOW5lzMBod9ElAxstPwGX0zFE6QslyT/VEItHResLcSkQJRVn0OhJs5SurHTmENfUfAbSplN6cugunrUShFmEjaFTFA2GzMSTWZ1fnqRzPtzq0vpjJ8/J/I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261640; c=relaxed/simple; bh=4f1230J9mhkITZY+w1m8RSOf+1e4vpyXxVg/Z7zZa9c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=acIU3oS7IAJXcuBCvkO8rgJ+2xGgJOuA29NfWySq75wNkBvmO71FkGrVnuSf5924epdS/HSraWOsgGTD5D3vKkD+gr/4ugtbjcWEVIvKuhjR74u0VKDLEE7pK2pr4AC6K9cgK/BOEPLc8erR62JU3oVoZaMVZcY7Kk0M/SQ7kok= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XXdIdP+y; 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="XXdIdP+y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72F71C4CEEC; Mon, 21 Apr 2025 18:53:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261639; bh=4f1230J9mhkITZY+w1m8RSOf+1e4vpyXxVg/Z7zZa9c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XXdIdP+yH8VOUv/H+9IHswdXjPbYDg3DlbaCO1ovD8ArmmoHiQyt60fFYPRE2qG33 cUDePFzm64SZ5sqU8ncCcC0NxgYE3CE8DfHcTBPGMUno+hpBX8vfZ1ZaOk4EsPx6ji ge5FHah11rgJK8wRmlx++j+g5EmDp5wVCmKaJn0ZA8cHElum/rNTx0Efd2bbbm40/I 6BrJexb0vKKRq9L5SgNsK7BBLKGs2TglU1smqwoxqzTMLWBStKnsiHJ/6y6V/bDupC hCpqUlndI50cjJxZAlbInbl7Cg2sL/MQ2avIFH6pLN81P6pTWRNVlP+AshDKZOXSbM GIl/dPNy42IHQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 25/29] x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables Date: Mon, 21 Apr 2025 20:52:05 +0200 Message-ID: <20250421185210.3372306-26-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" So append_e820_table() begins with this weird condition that checks 'nr_ent= ries': static int __init append_e820_table(struct boot_e820_entry *entries, u3= 2 nr_entries) { /* Only one memory region (or negative)? Ignore it */ if (nr_entries < 2) return -1; Firstly, 'nr_entries' has been an u32 since 2017 and cannot be negative. Secondly, there's nothing inherently wrong with single-entry E820 maps, especially in virtualized environments. So remove this restriction and remove the __append_e820_table() indirection. Also: - fix/update comments - remove obsolete comments This shrinks the generated code a bit as well: text data bss dec hex filename 7549 44072 0 51621 c9a5 e820.o.before 7533 44072 0 51605 c995 e820.o.after Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 35 +++++++++++------------------------ 1 file changed, 11 insertions(+), 24 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index ec5628a844dc..27bc45a65807 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -483,17 +483,22 @@ __init int e820__update_table(struct e820_table *tabl= e) return 0; } =20 -__init static int __append_e820_table(struct boot_e820_entry *entries, u32= nr_entries) +/* + * Copy the BIOS E820 map into the kernel's e820_table. + * + * Sanity-check it while we're at it.. + */ +__init static int append_e820_table(struct boot_e820_entry *entries, u32 n= r_entries) { struct boot_e820_entry *entry =3D entries; =20 while (nr_entries) { u64 start =3D entry->addr; - u64 size =3D entry->size; - u64 end =3D start + size - 1; - u32 type =3D entry->type; + u64 size =3D entry->size; + u64 end =3D start + size-1; + u32 type =3D entry->type; =20 - /* Ignore the entry on 64-bit overflow: */ + /* Ignore the remaining entries on 64-bit overflow: */ if (start > end && likely(size)) return -1; =20 @@ -505,24 +510,6 @@ __init static int __append_e820_table(struct boot_e820= _entry *entries, u32 nr_en return 0; } =20 -/* - * Copy the BIOS E820 map into a safe place. - * - * Sanity-check it while we're at it.. - * - * If we're lucky and live on a modern system, the setup code - * will have given us a memory map that we can use to properly - * set up memory. If we aren't, we'll fake a memory map. - */ -__init static int append_e820_table(struct boot_e820_entry *entries, u32 n= r_entries) -{ - /* Only one memory region (or negative)? Ignore it */ - if (nr_entries < 2) - return -1; - - return __append_e820_table(entries, nr_entries); -} - __init static u64 __e820__range_update(struct e820_table *table, u64 start, u64 size, enum e= 820_type old_type, enum e820_type new_type) { @@ -796,7 +783,7 @@ __init void e820__memory_setup_extended(u64 phys_addr, = u32 data_len) entries =3D sdata->len / sizeof(*extmap); extmap =3D (struct boot_e820_entry *)(sdata->data); =20 - __append_e820_table(extmap, entries); + append_e820_table(extmap, entries); e820__update_table(e820_table); =20 memcpy(e820_table_kexec, e820_table, sizeof(*e820_table_kexec)); --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 D8FA81FC0E2 for ; Mon, 21 Apr 2025 18:54:02 +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=1745261642; cv=none; b=AS/dEm4sAXcIdDVMJp8OxBziFO6Ih8A1uRrjfm5Xr1cN1TqVbVy87pmZfG+hnRWRXMke0Uc4xG4qmUHLbTqCU3sv2AvxBHLmI1vFzXuC6Fmr7Ba87m4Xyz0SZqZx/eVxvPwSdfZX4RHRKJZBnX22/EQ6kK19dfHfL0Nnu1hfTmM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261642; c=relaxed/simple; bh=VWNF9FhTByJK2MEjeB3RAXEpn0T069J0+BwcSw65894=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SePG2pNZg7TbaHy4oTKS86xt+FiMhEOullqglKNa35je+zilHBwgCFbKr9MxlB1c8ru5/Vns6Vu6K5NND0M1H4woD+ra+M6aAnYHFBGiAsOcgXiZRzbti9ftdO71KAcOVsHDnET0bmbLVcrzo1eo3MHoBTFSctoTphpAruyUjcE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PVyEU3Mp; 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="PVyEU3Mp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52FC1C4CEEB; Mon, 21 Apr 2025 18:54:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261642; bh=VWNF9FhTByJK2MEjeB3RAXEpn0T069J0+BwcSw65894=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PVyEU3MpRrDceG8FGLmb27ps9IDlJA1ADQ8B4lBLXg5CYcrAlNpX6e6f6Qfa+Bn+r Gw8hnty7ulhkdo77ha8RnYLxvLwp5L2RaKWFbALCig4EwIiBq7XEWXEgM/uoQjV5Nc SNd5So9QrMvGbIIHebw3bqq0TP1bXcEx9w1cDJTfZIHCF/XwXU1u/ev/gev625IA6t DC4sQWd0NXWsmREg380ilVndqN7IrjFLnAvjeOv9M+WC1L4lZGYapDWz6r7voQIyzy yN0y4OLac0AbN0DRcGLOzpa+FTo2f1g0cixnC4iGItz6r1ep4f6NB9ajYrfkz+rPr1 /0wOpPJBDN+/A== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 26/29] x86/boot/e820: Remove e820__range_remove()'s unused return parameter Date: Mon, 21 Apr 2025 20:52:06 +0200 Message-ID: <20250421185210.3372306-27-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" None of the usage sites make use of the 'real_removed_size' return parameter of e820__range_remove(), and it's hard to contemplate much constructive use: E820 maps can have holes, and removing a fixed range may result in removal of any number of bytes from 0 to the requested size. So remove this pointless calculation. This simplifies the function a bit: text data bss dec hex filename 7645 44072 0 51717 ca05 e820.o.before 7597 44072 0 51669 c9d5 e820.o.after Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/include/asm/e820/api.h | 2 +- arch/x86/kernel/e820.c | 8 +------- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/ap= i.h index 54427b77bc19..9cf416f7a84f 100644 --- a/arch/x86/include/asm/e820/api.h +++ b/arch/x86/include/asm/e820/api.h @@ -16,7 +16,7 @@ extern bool e820__mapped_all(u64 start, u64 end, enum e82= 0_type type); =20 extern void e820__range_add (u64 start, u64 size, enum e820_type type); extern u64 e820__range_update(u64 start, u64 size, enum e820_type old_typ= e, enum e820_type new_type); -extern u64 e820__range_remove(u64 start, u64 size, enum e820_type old_typ= e, bool check_type); +extern void e820__range_remove(u64 start, u64 size, enum e820_type old_typ= e, bool check_type); extern u64 e820__range_update_table(struct e820_table *t, u64 start, u64 = size, enum e820_type old_type, enum e820_type new_type); =20 extern int e820__update_table(struct e820_table *table); diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 27bc45a65807..2f9aecb9911c 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -590,11 +590,10 @@ __init u64 e820__range_update_table(struct e820_table= *t, u64 start, u64 size, } =20 /* Remove a range of memory from the E820 table: */ -__init u64 e820__range_remove(u64 start, u64 size, enum e820_type old_type= , bool check_type) +__init void e820__range_remove(u64 start, u64 size, enum e820_type old_typ= e, bool check_type) { u32 idx; u64 end; - u64 real_removed_size =3D 0; =20 if (size > (ULLONG_MAX - start)) size =3D ULLONG_MAX - start; @@ -617,7 +616,6 @@ __init u64 e820__range_remove(u64 start, u64 size, enum= e820_type old_type, bool =20 /* Completely covered? */ if (entry->addr >=3D start && entry_end <=3D end) { - real_removed_size +=3D entry->size; memset(entry, 0, sizeof(*entry)); continue; } @@ -626,7 +624,6 @@ __init u64 e820__range_remove(u64 start, u64 size, enum= e820_type old_type, bool if (entry->addr < start && entry_end > end) { e820__range_add(end, entry_end - end, entry->type); entry->size =3D start - entry->addr; - real_removed_size +=3D size; continue; } =20 @@ -636,8 +633,6 @@ __init u64 e820__range_remove(u64 start, u64 size, enum= e820_type old_type, bool if (final_start >=3D final_end) continue; =20 - real_removed_size +=3D final_end - final_start; - /* * Left range could be head or tail, so need to update * the size first: @@ -648,7 +643,6 @@ __init u64 e820__range_remove(u64 start, u64 size, enum= e820_type old_type, bool =20 entry->addr =3D final_end; } - return real_removed_size; } =20 __init void e820__update_table_print(void) --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 B700F1FF1B3 for ; Mon, 21 Apr 2025 18:54:05 +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=1745261645; cv=none; b=ZU7LaqRRx8YQ6g23tnEdQDoB8VX9E7hU/prQXliUVBON4qS9Z17p5s706PlxES5GaL3J86MMUCtxItg6rrMLRt1JR9PLUhvpxVSXZbd3SW9Yh+0MrD3VATZzFjzq6Nc1ifjwBp4m1VU4DcRSOlBuyGoeSJ3K1lrDpvT/f3QrwxM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261645; c=relaxed/simple; bh=3RbIn7SitXxqrANelTJi6yFiJss2rMhwM+hqSc9DXm0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PjSh7JuRQYVSIu4E54xBUaRb4n//pblujkD3BcvOlzdOtzA2AQvGIw+pENDTJG7/+RFdFwOPCKC3+yVo82HtUiAPsIxqY157cxnUQxfjPaNljYy3z7yzZWzCYKf2uhKVuN9aKwh4j6IkwPVK7CAifgZBqHP3gWtVu4mFuoyKLhw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LJMr6FGi; 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="LJMr6FGi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25E69C4CEE4; Mon, 21 Apr 2025 18:54:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261645; bh=3RbIn7SitXxqrANelTJi6yFiJss2rMhwM+hqSc9DXm0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LJMr6FGi0oLvgOlsjxmLzq5GtWsea/KO8UeGFmlOTtOYoB53CRarcNczRsWzqHuF8 D97NWTxp68BBqIrOg4kTLJvLVJAdUUwVkNv7tRXC/+M0f9LCDv8Br+xJzvOaICV2tN 14PgddN0wjh0AP2nmQZkw8RG5AUJjuD8j9il77MRvUMfGYnRp2InhEpOIpRKqZL76i dt9XXp7FPJNraw41ez8I7i/pdEgjVOH3iKlvlE7bf2LvdFGKy8iKAQ+C1wAUgQWBTs wjq3Xqx2qa0phb7iCFANmXEeXg3iZ4ek2/Yk106UUogxNVXgON1TxETdKFHSXKS+Y6 SoJjeUpJptOaA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 27/29] x86/boot/e820: Simplify the e820__range_remove() API Date: Mon, 21 Apr 2025 20:52:07 +0200 Message-ID: <20250421185210.3372306-28-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Right now e820__range_remove() has two parameters to control the E820 type of the range removed: extern void e820__range_remove(u64 start, u64 size, enum e820_type old_typ= e, bool check_type); Since E820 types start at 1, zero has a natural meaning of 'no type. Consolidate the (old_type,check_type) parameters into a single (filter_type) parameter: extern void e820__range_remove(u64 start, u64 size, enum e820_type filter_= type); Note that both e820__mapped_raw_any() and e820__mapped_any() already have such semantics for their 'type' parameter, although it's currently not used with '0' by in-kernel code. Also, the __e820__mapped_all() internal helper already has such semantics implemented as well, and the e820__get_entry_type() API uses the '0' type to such effect. This simplifies not just e820__range_remove(), and synchronizes its use of type filters with other E820 API functions, but simplifies usage sites as well, such as parse_memmap_one(), beyond the reduction of the number of parameters: - else if (from) - e820__range_remove(start_at, mem_size, from, 1); else - e820__range_remove(start_at, mem_size, 0, 0); + e820__range_remove(start_at, mem_size, from); The generated code gets smaller as well: add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-66 (-66) Function old new delta parse_memopt 112 107 -5 efi_init 1048 1039 -9 setup_arch 2719 2709 -10 e820__range_remove 283 273 -10 parse_memmap_opt 559 527 -32 Total: Before=3D22,675,600, After=3D22,675,534, chg -0.00% Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/include/asm/e820/api.h | 2 +- arch/x86/kernel/e820.c | 16 +++++++--------- arch/x86/kernel/setup.c | 4 ++-- arch/x86/platform/efi/efi.c | 3 +-- 4 files changed, 11 insertions(+), 14 deletions(-) diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/ap= i.h index 9cf416f7a84f..bbe0c8de976c 100644 --- a/arch/x86/include/asm/e820/api.h +++ b/arch/x86/include/asm/e820/api.h @@ -16,7 +16,7 @@ extern bool e820__mapped_all(u64 start, u64 end, enum e82= 0_type type); =20 extern void e820__range_add (u64 start, u64 size, enum e820_type type); extern u64 e820__range_update(u64 start, u64 size, enum e820_type old_typ= e, enum e820_type new_type); -extern void e820__range_remove(u64 start, u64 size, enum e820_type old_typ= e, bool check_type); +extern void e820__range_remove(u64 start, u64 size, enum e820_type filter_= type); extern u64 e820__range_update_table(struct e820_table *t, u64 start, u64 = size, enum e820_type old_type, enum e820_type new_type); =20 extern int e820__update_table(struct e820_table *table); diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 2f9aecb9911c..b4fe9bebdeb5 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -590,7 +590,7 @@ __init u64 e820__range_update_table(struct e820_table *= t, u64 start, u64 size, } =20 /* Remove a range of memory from the E820 table: */ -__init void e820__range_remove(u64 start, u64 size, enum e820_type old_typ= e, bool check_type) +__init void e820__range_remove(u64 start, u64 size, enum e820_type filter_= type) { u32 idx; u64 end; @@ -600,8 +600,8 @@ __init void e820__range_remove(u64 start, u64 size, enu= m e820_type old_type, boo =20 end =3D start + size; printk(KERN_DEBUG "e820: remove [mem %#010Lx-%#010Lx]", start, end - 1); - if (check_type) - e820_print_type(old_type); + if (filter_type) + e820_print_type(filter_type); pr_cont("\n"); =20 for (idx =3D 0; idx < e820_table->nr_entries; idx++) { @@ -609,7 +609,7 @@ __init void e820__range_remove(u64 start, u64 size, enu= m e820_type old_type, boo u64 final_start, final_end; u64 entry_end; =20 - if (check_type && entry->type !=3D old_type) + if (filter_type && entry->type !=3D filter_type) continue; =20 entry_end =3D entry->addr + entry->size; @@ -945,7 +945,7 @@ __init static int parse_memopt(char *p) if (mem_size =3D=3D 0) return -EINVAL; =20 - e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1); + e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM); =20 #ifdef CONFIG_MEMORY_HOTPLUG max_mem_size =3D mem_size; @@ -1001,12 +1001,10 @@ __init static int parse_memmap_one(char *p) e820__range_update(start_at, mem_size, from, to); else if (to) e820__range_add(start_at, mem_size, to); - else if (from) - e820__range_remove(start_at, mem_size, from, 1); else - e820__range_remove(start_at, mem_size, 0, 0); + e820__range_remove(start_at, mem_size, from); } else { - e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1); + e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM); } =20 return *p =3D=3D '\0' ? 0 : -EINVAL; diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 83cc265140c0..0f4d78939005 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -736,7 +736,7 @@ static void __init trim_bios_range(void) * area (640Kb -> 1Mb) as RAM even though it is not. * take them out. */ - e820__range_remove(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_TYPE_RAM, 1); + e820__range_remove(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_TYPE_RAM); =20 e820__update_table(e820_table); } @@ -758,7 +758,7 @@ static void __init e820_add_kernel_range(void) return; =20 pr_warn(".text .data .bss are not marked as E820_TYPE_RAM!\n"); - e820__range_remove(start, size, E820_TYPE_RAM, 0); + e820__range_remove(start, size, 0); e820__range_add(start, size, E820_TYPE_RAM); } =20 diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 463b784499a8..d00c6de7f3b7 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -333,8 +333,7 @@ static void __init efi_remove_e820_mmio(void) if (size >=3D 256*1024) { pr_info("Remove mem%02u: MMIO range=3D[0x%08llx-0x%08llx] (%lluMB) fro= m e820 map\n", i, start, end, size >> 20); - e820__range_remove(start, size, - E820_TYPE_RESERVED, 1); + e820__range_remove(start, size, E820_TYPE_RESERVED); } else { pr_info("Not removing mem%02u: MMIO range=3D[0x%08llx-0x%08llx] (%lluK= B) from e820 map\n", i, start, end, size >> 10); --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 E3A181EB5D8 for ; Mon, 21 Apr 2025 18:54:08 +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=1745261649; cv=none; b=hPw6GtOlrS+qqLgDrQKClkPGcfU8+zl8kJTMnBa0q9YzQv7y2U94LjLmd/96nVzv7zExsj+tmNpOwW0wEca10JAJeK6E7e4h3/lIV/XMsHlqXQUbwbCHLvAdk8WZamMSFU5glJZ72hrOxXS/4UTuB7aOr4sEnRKOm7/T6dM4o64= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261649; c=relaxed/simple; bh=QM6gH9TCIv+vanB5Oeg/F4HH+ytmYasNSeoe7V/A8Sw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W/Vu2TLu9rmfr1T151lH380lDh3ruTf9aBK75xOWn5IM8phZYTXSLRu/B4yp4GnSspy4SIlAQVbWlxvfXDMuMX/DxyjSwfOZV0bWORwXV/8oE6V9gFXFDeTfQe/ytVpYaPMh721M0XnYo04bwbkr5jqBLS0VKLMw6f332UVO7H0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kDi9ShJT; 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="kDi9ShJT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF408C4CEEC; Mon, 21 Apr 2025 18:54:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261648; bh=QM6gH9TCIv+vanB5Oeg/F4HH+ytmYasNSeoe7V/A8Sw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kDi9ShJTYNosbQNhCkJl3jtTrObzUiD4pxN6uQ6a29ZKkTh1kzWWq2G4sMdye8vvi 7TPXspkDZZ6TQTRaOQExDfqXlLWhBm4zNi4EqUH7z0WqL7p3WNTVrOkvspwE6eelZA gtrg/jTSZuqf2W9o8bxHmdjV6Ptlpod8AUn/qTAVdzqAvD8uJQUmCWSHxxVUdiLimL 35RoiQQxalJ70Vzwt0pq5J+HyHJqmQTHPjCtThII2WzOToOCyxipui/2u2Jtv7eJ7y dn3vaAgvAJQ4wjm7QYFlV4Zv4V4IXU+rUx/ZZI1cF5iJWX7TBQ9b8m/zViXoJ9a/OU vJHWe6d5ohs0g== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 28/29] x86/boot/e820: Make sure e820_search_gap() finds all gaps Date: Mon, 21 Apr 2025 20:52:08 +0200 Message-ID: <20250421185210.3372306-29-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The current implementation of e820_search_gap() searches gaps in a reverse search from MAX_GAP_END back to 0, contrary to what its main comment claims: * Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB). But gaps can not only be beyond E820 RAM ranges, they can be below them as well. For example this function will not find the proper PCI gap for simplified memory map layouts that have a single RAM range that crosses the 4GB boundary. Rework the function to have a proper forward search of E820 table entries. This makes the code somewhat bigger: text data bss dec hex filename 7613 44072 0 51685 c9e5 e820.o.before 7645 44072 0 51717 ca05 e820.o.after but it now both implements what it claims to do, and is more straightforward to read. ( This also allows 'idx' to be the regular u32 again, not an 'int' underflowing to -1. ) Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 59 +++++++++++++++++++++++++++++++++++-----------= ---- 1 file changed, 41 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index b4fe9bebdeb5..f9caf4c922ea 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -666,30 +666,52 @@ __init static void e820__update_table_kexec(void) */ __init static int e820_search_gap(unsigned long *max_gap_start, unsigned l= ong *max_gap_size) { - u64 last =3D MAX_GAP_END; - int idx =3D e820_table->nr_entries; + struct e820_entry *entry; + u64 range_end_prev =3D 0; int found =3D 0; + u32 idx; =20 - while (--idx >=3D 0) { - u64 start =3D e820_table->entries[idx].addr; - u64 end =3D start + e820_table->entries[idx].size; + for (idx =3D 0; idx < e820_table->nr_entries; idx++) { + u64 range_start, range_end; =20 - /* - * Since "last" is at most 4GB, we know we'll - * fit in 32 bits if this condition is true: - */ - if (last > end) { - unsigned long gap =3D last - end; + entry =3D e820_table->entries + idx; + range_start =3D entry->addr; + range_end =3D entry->addr + entry->size; =20 - if (gap > *max_gap_size) { - *max_gap_size =3D gap; - *max_gap_start =3D end; - found =3D 1; + /* Process any gap before this entry: */ + if (range_start > range_end_prev) { + u64 gap_start =3D range_end_prev; + u64 gap_end =3D range_start; + u64 gap_size; + + if (gap_start < MAX_GAP_END) { + /* Make sure the entirety of the gap is below MAX_GAP_END: */ + gap_end =3D min(gap_end, MAX_GAP_END); + gap_size =3D gap_end-gap_start; + + if (gap_size >=3D *max_gap_size) { + *max_gap_start =3D gap_start; + *max_gap_size =3D gap_size; + found =3D 1; + } } } - if (start < last) - last =3D start; + + range_end_prev =3D range_end; + } + + /* Is there a usable gap beyond the last entry: */ + if (entry->addr + entry->size < MAX_GAP_END) { + u64 gap_start =3D entry->addr + entry->size; + u64 gap_size =3D MAX_GAP_END-gap_start; + + if (gap_size >=3D *max_gap_size) { + *max_gap_start =3D gap_start; + *max_gap_size =3D gap_size; + found =3D 1; + } } + return found; } =20 @@ -706,6 +728,7 @@ __init void e820__setup_pci_gap(void) unsigned long max_gap_start, max_gap_size; int found; =20 + /* The minimum eligible gap size is 4MB: */ max_gap_size =3D 0x400000; found =3D e820_search_gap(&max_gap_start, &max_gap_size); =20 @@ -725,7 +748,7 @@ __init void e820__setup_pci_gap(void) pci_mem_start =3D max_gap_start; =20 pr_info("[gap %#010lx-%#010lx] available for PCI devices\n", - max_gap_start, max_gap_start + max_gap_size - 1); + max_gap_start, max_gap_start + max_gap_size-1); } =20 /* --=20 2.45.2 From nobody Tue Dec 16 09:14:24 2025 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 56FD61EF0A6 for ; Mon, 21 Apr 2025 18:54:11 +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=1745261651; cv=none; b=azpMciJ4YNDf1QmazD6dCgTTO+enCsNJKHhCC2ZEaM+XxY0VHkBSouIMEbl3nfFIwqokfB3zVBkx9gdEOE31MreYIO/+7N+qwpjsr08xLzlJfhJ9jXHia2PVDZkp24yVLt+1ZxcORd7JBZUKnZNLWPldfH0+fjddVqwB08x9m6g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745261651; c=relaxed/simple; bh=8dqxYJzFH0LdMCALju2Kx9n/AXIDOW004jSqtWom7ZU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RVghvehmsvolnZ9xqcsg40/XHkSsk28h5eRJfIQAeHvDMWOivvl3VtyulcRLRpRfchm19iP6CU6xssGM1VEnSzysrcr5ZZM6NOp8teSF3Vj1FLOO/XCxMOvzELtjHu+s3Y2jOfQc81s3J6hOih5gJy4gsS779CGaQ0kiJCqa9E4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OuPdEqV2; 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="OuPdEqV2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3C30C4CEEA; Mon, 21 Apr 2025 18:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745261651; bh=8dqxYJzFH0LdMCALju2Kx9n/AXIDOW004jSqtWom7ZU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OuPdEqV2w2o7F+mKk0BuSKBsPzTgBvRGB3SzxPCExQwT0Q470oP/bqG+H8rLpyEo/ 95UZWLL6WjMHZYCjtYYhhpur1KRhyNTf2jV0aU+5v7ItXhRiWI5WkePNOH+9DRJ8jb cqvaZWQqopP/63E7quExlAGVW5WOltXHHat+RNytkQKdBYjgC/As1CZZPc4t8i31+w 1yUJRKQdFSq3Xn9mfJ0YNXVPuEYLg6YrLYdEQTcI9poLOSVJbIHo9Pz49sQhAqxNpY LTOEUmI0+MLKE/ySluZT2VvPdlzXhjTi/qYKUa06//h3PS3UCR91AGLr5f0leXpUTC nFZGATRj5SYBw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse Subject: [PATCH 29/29] x86/boot/e820: Treat non-type-2 'reserved' E820 region types as E820_TYPE_RESERVED Date: Mon, 21 Apr 2025 20:52:09 +0200 Message-ID: <20250421185210.3372306-30-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250421185210.3372306-1-mingo@kernel.org> References: <20250421185210.3372306-1-mingo@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Paul Menzel pointed out that ACPI specification 6.3 defines 'reserved' E820 region types as E820_TYPE_RESERVED (type 2): > Table 15-374 *Address Range Types* in the ACPI specification 6.3 says: > > > Reserved for future use. OSPM must treat any range of this type as if > > the type returned was AddressRangeReserved. This has relevance for device address regions, which on some firmware such as CoreBoot, get passed to Linux as type-13 - which the kernel treats as system regions and registers them as unavailable to drivers: static bool __init e820_device_region(enum e820_type type, struct resource= *res) ... case E820_TYPE_ACPI: case E820_TYPE_NVS: case E820_TYPE_UNUSABLE: default: return false; Users of such systems will see device breakage on Linux, which they have to work around with iomem=3Drelaxed kind of boot time hacks to turn off resource conflict checking. Follow the ACPI spec and change the Linux E820 code to treat unknown/reserv= ed E820 region types as E820_TYPE_RESERVED device memory regions. Reported-by: Paul Menzel Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Mike Rapoport (Microsoft) --- arch/x86/kernel/e820.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index f9caf4c922ea..c36261d78109 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -1140,8 +1140,10 @@ __init static bool e820_device_region(enum e820_type= type, struct resource *res) case E820_TYPE_ACPI: case E820_TYPE_NVS: case E820_TYPE_UNUSABLE: - default: return false; + /* Reserved E820 types should be treated as device memory regions: */ + default: + return true; } } =20 --=20 2.45.2