From nobody Wed Dec 17 03:27:47 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 21962298C24 for ; Thu, 15 May 2025 12:05:59 +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=1747310760; cv=none; b=OfK3B6MjDRIG9NL57hwVAXdc/5oCLajiduow7dMpZGlG1jaETaglPK7TSUWLIo78cx/K4E0WdkGQd3Zrm+ocF81WnR7fIh4/Gc5uksv+LDGQ+GDVikMyYUwTnOcJ04/jiVUxd0k1CSHFvjvX9UjTXeNnJw3SvXsUUitz8pIuqRw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310760; c=relaxed/simple; bh=PkxFxlS2ufBqBcCmqi1+E4bmWxFN2KmJBbEKLEdB5CE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=s2U5piu/PhPN3ULSS1mPMa5es0dzlAOZFkA/mxdItQ1/JMl9YAVLB14gnja+/Ev8kZaG9DIbcKc3XpepDxsCyvCURI2S3+SINkuLTjEuK2FinQKen1AHhqWeUvqXgvj7HB9XnnD/Ou9VctRZ/cSmGZ+NwyBNEdKU6IKGR77ULvc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UA6HRVsd; 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="UA6HRVsd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92F28C4CEED; Thu, 15 May 2025 12:05:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310759; bh=PkxFxlS2ufBqBcCmqi1+E4bmWxFN2KmJBbEKLEdB5CE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UA6HRVsdE7xAJH5aNceAFHGRdupWaIU6tBLXi7RyRIf/YlZ4nLhwsRt5rIXYCaZMk Jlda4RtjlU5fLMGU3Xja+5/dGvbhV6F4tvQc/9CSfquTf269kRML7hYGZFffv/wFh3 S7tDcHKUfsSHrtFmPsCj0r+iNmCexAAA0N4UQHtiBqcJGJVFIUOw0v8+emWj64RXg9 UW//NKUvP/bC65OF5dsAHxQlS0QtFkkywXb6dejFH/rAXzdDCFGzPGWKkGjxmLG9f9 EglCnQEBJJYIwV865rPyil/e/PlNR9+JPj6h0bUBBvE44YOIyEra7w+jo1Y1+uho8n 2m9X0PLe3L7Ww== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 01/32] x86/boot/e820: Remove inverted boolean logic from the e820_nomerge() function name, rename it to e820_type_mergeable() Date: Thu, 15 May 2025 14:05:17 +0200 Message-ID: <20250515120549.2820541-2-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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) Reviewed-by: Nikolay Borisov --- 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 9920122018a0..b95f0519a877 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 Wed Dec 17 03:27:47 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 3672D298C24 for ; Thu, 15 May 2025 12:06: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=1747310763; cv=none; b=hP1DxF9Y+XM/N/o6s615vU4EdsvHmDwC/dW3iFeXde/YNOut/Yk25z1NYCU2aOnsvp+oukTtTxKCt8ODqAVXS5pGr1O78IGT565WRioDJAOHoETR2WT6LPUzQbWZK6IRoH4hLuUBTMshBp5WPVET2WSIcED8n1F2GJc05hwyaNc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310763; c=relaxed/simple; bh=Driw6whNzZPzvROzbR0jpYx5SAkwmYkvQXz66nnFPnM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eEi+Y9jE06qprsfaopmLgKlOX6yc58xHjkI/Yl+opunIIz0bmW/WnP33sn/CYz7cH1T/QTMDQHSImBnGmARN4dPuuQgn6iRaVbmnBjc4fQPNGnZIMijQlqt1Ltovqog3VRul89HYmhxUWe1OF3fTRLxveKeAm13LomrZOIC+L8Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mfMFQdO4; 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="mfMFQdO4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14547C4CEE9; Thu, 15 May 2025 12:05:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310763; bh=Driw6whNzZPzvROzbR0jpYx5SAkwmYkvQXz66nnFPnM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mfMFQdO4zFf1eQco3Vplfu63m7/R6APTfaAQKB1pxC0qeBaBDrp5DKkOPY+W3+//M jVmr0HzfGwt7sbHIqvoMF91/Mf+jXhSHBhEwfu3EAoW8RMgknB9v4MAw2E17asM2Pk DSXgF2P6KCDkvp6aZgUR4XzH4YzNbdc8y5gDobFZke55lxWRqetLRInZc8W4J8ecb6 87enNC43O4untweQng35BzHQ1HkjG/LUKTOQBr+cRDUlNx6CN/7LFW9/QyduyIvfon JPcYSHIMqhZEMw9ZFIL/hXfQ8UkxW3jENuDx0a/aY8waPB+eDUl8dteameCjvkdB2u 6QbxStdhI2ZwQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 02/32] x86/boot/e820: Simplify e820__print_table() a bit Date: Thu, 15 May 2025 14:05:18 +0200 Message-ID: <20250515120549.2820541-3-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 b95f0519a877..904925159560 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 Wed Dec 17 03:27:47 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 1886F2989BD for ; Thu, 15 May 2025 12:06: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=1747310767; cv=none; b=U7qJzSN/1O75fzKEXS1qNi0MEmc1RqLLhqTP8KuV7HNOm6BU5zo/FC9XH5PCNaszaIyKv0beGvx3wM4/vS+eHrvRaCy0jJne01e+t70AslcpCgxVc0dFHwufH0E+Z31GoAfJ9jFXmpZ3nALEs5xclRCY+Cji6E+4saaxgaBP5eQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310767; c=relaxed/simple; bh=k4jykQV1oqIHmudTK/CHYBW3w0kECTCzyR+C3gMwcJw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IFr0mQ1CSO9QWQAV1iCdkuVxcIjJn1fT5afeB5pfTN6ljGcbgXwPGyRFvuPHtUkLe1Bm+drKAaUh+6fiYNjwdNskT6IB+7/kcW6RTciWBbNIiaaoAW/48Afk5DKcd1OLHavX317OWBxL2MXPj1KFIufnjW7PTAPD5ylK+qLQeFE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RCTbsz/O; 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="RCTbsz/O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88190C4CEE7; Thu, 15 May 2025 12:06:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310766; bh=k4jykQV1oqIHmudTK/CHYBW3w0kECTCzyR+C3gMwcJw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RCTbsz/OQbDvVGciSrfokIYRilNXj6qPQTohsT4U1eaEejTMSi3P9dQfL+C/l8YrE GrdzrsldglWU6yUYOdyivC0VzPJTrDY26zG4tHZACisSq6Bm40NDvxX5kDBgbaJem3 MJ5eMYbm7rzvpZLNL8b1Gu0MSHFKe0c1vIK79nAjo8VIPu9I9Ocewh0dbq0tYEpYab 6h1uz33TxYTWdv4ivpn4QhUR/vkZ7ejiuY+lXUNlstjoik2Jj5p07UVpXg1v8Jt/v5 yI8cStxn0sr3eUkSbvOx9Ix9j6kt3uA6laiAf8eG9nULn6i6kQ/oTRTs/l+PxJU2R4 WrHsFJ9FWX1kw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 03/32] x86/boot/e820: Simplify the PPro Erratum #50 workaround Date: Thu, 15 May 2025 14:05:19 +0200 Message-ID: <20250515120549.2820541-4-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 7d9ed79a93c0..f40dffc3e014 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -984,11 +984,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, SZ_256K, E820_TYPE_RAM, E820_TYPE_RESE= RVED); 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 Wed Dec 17 03:27:47 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 95889298C18 for ; Thu, 15 May 2025 12:06:10 +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=1747310771; cv=none; b=AytkQL8y9uDGbix9c8MSXlQE0+1WlJ+S5dhiLE/TLUMs+sT9z28l8MVVg/wpbRmlQsx7cdIEt7hR0ImeVq0aFONOx+h9A/YcgImx28yR2qVYXjxiPptHpSX20hCLLHInG7Zju9IooFAuzKVxjdCuV4R4J2a30zsvzOHSGAevdXg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310771; c=relaxed/simple; bh=upyXvboQNP6OB56g1KHwVmRbpdgsLNWFMyyDrRGxVQU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mAmfe+b3id0ibCHXKdZkuecR2Qx0vYbMJZGqEyjMXVu4J0fCG3FGWEo2B/EaZqUsbmc0sFRq7e73irtUXvddlJc+tSvH1ouTOxBSND73rbZIkrvsbPx8eWP34HSP/eqxyIowszCxXoJQHPLWK1ugn6QzYhSoVudp6+tgJdwZylg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bYY2yZFz; 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="bYY2yZFz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F3DCC4CEE9; Thu, 15 May 2025 12:06:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310770; bh=upyXvboQNP6OB56g1KHwVmRbpdgsLNWFMyyDrRGxVQU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bYY2yZFzCIf0imNVcs41i5EMC/EKWFJJKYqo4VCtnKWPDMIUd1QaGd2KjeqIEFs0Q 4ITC7CmdWGBZVtT6rnN84ryD3rifLPGOvO4Y7Nmsmk7UvMW+PsKQLtPGYyTZIT4Y7g 7lG58Dn6HPwPTZBC0uzDslgwHa/xHDLI0fImh/9sZ69iaKUW1el2si4SsopbusV7ST 7kBbvx81h/F+YU3ij7ugDp+63CyGaiurmR/VFQXWvYfmRKFbuNzsdSbnw2X8qVfFiH /di0EeVPiIS7+aAg8JIl3rlB3w19lEfmhFcERF2drmsomi7BxUYVxdv9oUYVcz7wE7 RkoqrZVc1FoYg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 04/32] x86/boot/e820: Mark e820__print_table() static Date: Thu, 15 May 2025 14:05:20 +0200 Message-ID: <20250515120549.2820541-5-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 904925159560..c7911d2054fe 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 Wed Dec 17 03:27:47 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 A5703298C1C for ; Thu, 15 May 2025 12:06:13 +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=1747310773; cv=none; b=u7HGaxmOmwBtV6eAhWEGWVCk6SNwmTK2Hi8TElig6jJ8CigT2LvPKq5DHTAFpo/iBQ7QLhatTy4xW69p7WQaKth4uTPAH5oA3PAFppE2zwUOTvGz2564cN8OvMQgFwQoHE6WXlXvYJ82Bn2bGq8wJiWuLzNJBLzapJEpOGCGXFU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310773; c=relaxed/simple; bh=qnej4L0lOeFTPoLPsMDFf5FZ9eFt0NnAXBwokH8CudI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U+EIxOQh2ZOljUEAaj0/W8hO5Va1eRNcNp9kIjTUXI7q1wvoF2l+HhXg0jREkJBb+i+D39SrlJMSMEsCL+T+AEubblt255r0El1HkPPJY0k46vfNfac57R606AyhEmGF4EfgcVe0vtdarfG7LWgHOoIOsApGTGGIPvshX1ppcKc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bUDrUmdG; 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="bUDrUmdG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84218C4CEE7; Thu, 15 May 2025 12:06:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310773; bh=qnej4L0lOeFTPoLPsMDFf5FZ9eFt0NnAXBwokH8CudI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bUDrUmdGi+3nQHO3It5Jg402UI467svRLFyr/oTJC1UvI2UEqCeJNx2B+tq19KtCd 4YShu35kbxz3d60eRn8Hl2MqrRqWwE1Xqia/W6Ol5uKjwNQdzM30Hl+PV2uBkNtz/n w6jTFwBkI/Z3RB/uEZnmYq+9xxaef0sQXHQKF+XctCdJPaCsrwtDkrWmY7KvNlkmSe Vs5weUnb0u2TeWQdQ/Bfh0gYsoZWVU7q/tj+qi+rkaGtPhOnzRxJSKn5D7GMbrUcrC boINDmg/oSlG8rij77yUu3dg1PRXcmzkxZl40adoSGseetaQ2jx6VI4hsE5xJJJmZe u5bRc3DWDdJ1w== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 05/32] x86/boot/e820: Print gaps in the E820 table Date: Thu, 15 May 2025 14:05:21 +0200 Message-ID: <20250515120549.2820541-6-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 c7911d2054fe..c8833ac9cbf9 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(FW_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 Wed Dec 17 03:27:47 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 8999F2253B5 for ; Thu, 15 May 2025 12:06: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=1747310780; cv=none; b=qlWpJ4iTbedJOhtOou8rr923Ok+eFbh/wuKvraH+bZalJHsqKF4/lDitcEpKgw9+AK/lrd0g85Sax590ucF9afiOWH7gbHqItnB8xbKt2ybz/Da4ulkUHMXaITcu2Rkl4++oWieA1bI3n0VcI3OHIPX/Dqsded8QWhm0tIm12hs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310780; c=relaxed/simple; bh=7J39RAUo56IzYFcoL3Vhi/KBYwcP/BbcQYyfAPFNzKs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=e7o12I0DSdTFHzlTe2iGj8UohHBv/h1cEG+3JgY++7fq4NIXtx+F8jGxK7y381y9soJ/iAbWlHSTmZc0eEjcZAJv4eSUp5lnVmyODANsAOfYuisxrsOn0qrgudHUrk1OfCHB0eC12UWAoer2RBAyJeQFYhQt+zsSupJrw342Bmo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qJUYDHVH; 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="qJUYDHVH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05456C4CEE9; Thu, 15 May 2025 12:06:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310777; bh=7J39RAUo56IzYFcoL3Vhi/KBYwcP/BbcQYyfAPFNzKs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qJUYDHVHj8sGWtDCGYau/lbAiX4Qs1JCWFHYQXmyUn8tqTK+c3oGg0uSEM/ay2FkQ 3wENwq6snu9Kfqzf2vagaY970wpdMMaY74VN5ojCCwfdfACr4s6A6xAXxcrS5B8s7u DrOVRBEHx9cx7Z89r8++4c3bKvHlAXrjSu8/PoAfpBP+ylUCjJKb0jOYB2gYuqLWwJ 7RF/EaxNf8+WnYD3RKJTtzjGa3FwTv0g2wPz9bFPVkhK7AwhcLNYc4UF33C6IJSGNH D8R91Ab2AY0w2SZGj6ZCJuXNnStO3lGmqRdRdDnQeV6v6yVkK/uXoYtYpaJPg2v6f2 lhFFK5EFPIdjA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 06/32] x86/boot/e820: Make the field separator space character part of e820_print_type() Date: Thu, 15 May 2025 14:05:22 +0200 Message-ID: <20250515120549.2820541-7-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 c8833ac9cbf9..b5895b142707 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 Wed Dec 17 03:27:47 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 99E67253923 for ; Thu, 15 May 2025 12:06: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=1747310780; cv=none; b=j6XpBdrZpCr0R3++QzpYQnuGKQ4ryFIyA77otpg/82QUmOjW6pYa8lyEjcM41vSoRAghaXxd/S5AeLDyChQveCDgBKbs23a2wiyFk4B4skQSusoQlMoQIuD8b0wTN5utX3JUtni5Gt3SEllVEXgFtwi8Y1hRvlg4AeHnwrtXdwc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310780; c=relaxed/simple; bh=/hqQLt0YCUGR5KS01ppLduzN+UlLPP94cAlEHdbjuc4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qGTL6pip/uEjfHGMdEvDJsOdl4CtUTds00CqCgBsOI9Bht8cRzTDA1DjAcUh8e2BQCWDFWW6WLmKr43iQDrmPkMQ5hd2bZslcJmTdJHO09OPmXzLwdBTBVZ9QVsBP/npnmboYbHlCpVbfKrOolgC2xgZxxxvVWFSvWM8wLnuN+g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DMDx/jWb; 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="DMDx/jWb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79011C4CEE7; Thu, 15 May 2025 12:06:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310780; bh=/hqQLt0YCUGR5KS01ppLduzN+UlLPP94cAlEHdbjuc4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DMDx/jWbLjQpOVlojez//DCtJIqN7xFso4dJUanEmpuDeoJOKt64Qco7MxV0QAmq4 uOL+ICthgIg/5xvlIAPNHOeilYZNWGtoPrUZ7dADDIVi1TmghkweXvqeu6WTY5my4D 3LF4LkPJLzMGwDDdcEyP+uGT4ttP/l1HwpDUar4Gwc2fkitCopi5PqUs68nByWf+1A asRR6qm9UJoYbtNplORG7lyy5d0nOSQugt+/FZBXudOMNCojz9xkdj61wewFp8vfXV AcYvo9SiNROYpa/qgIH4A+gVdBeJmAojYexl+0s7ZWfvz9EI1aTuR3ny++BmPmCoiB OgEHdq99i/b/Q== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 07/32] x86/boot/e820: Print out sizes of E820 memory ranges Date: Thu, 15 May 2025 14:05:23 +0200 Message-ID: <20250515120549.2820541-8-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 b5895b142707..7f600d32a999 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(FW_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 Wed Dec 17 03:27:47 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 8BD40253923 for ; Thu, 15 May 2025 12:06:24 +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=1747310784; cv=none; b=aDPrJbhFPBJEcaHA8Wt5pBSkeJwIuGAD1P6XYzXtaeM7MkjhKgLP6c9pHWOsodY5JSugkFgSIAqoJzdG7p3PmshXXKcjcVjAUbCQBfNGsWyXiU1UqcEVz4w+Utn34PmCCN4VdQPC/Vp2QOUrBQM2YD4xjH4uDfRIYIRsxWUK93M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310784; c=relaxed/simple; bh=zp7SIN7s30Adozj+y2qmFjn+RbOfC2rbFOJHPlbNL5U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ra9MWI8Nu6ocIT8BicIoNYc+Wf/J1+YJsPC1pzI8YxcWkanqAlj+VAT9kJrftBR8r676kaOzTinuHzU6jvYVcqHoawvHHy2+VXH4nYIj0magWC08InYokkQbK5vRLvf4dwi5mcLZKPco6EMAypW8/ypD5IlrQt28GQYwTvMsD28= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V6M3EDwO; 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="V6M3EDwO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE229C4CEF0; Thu, 15 May 2025 12:06:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310784; bh=zp7SIN7s30Adozj+y2qmFjn+RbOfC2rbFOJHPlbNL5U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V6M3EDwOhdniVLWLwIiDZ4RxKI8mkbcmcrkKwqOtAzwQLhdWJAnhQBGi5DKj4ULI+ ewtWr1n/LH5hFCZd0uJrBq126AIDxdPYacOHq+yFT4g+FxHERg0pXW90oVGrXwBumT IpO09lUpxLkWIfxfcUUMx5eux95ORLMJozjFjBaH9v+BvEwd8p7t+msvIJSLNxESMV XaDVcl6vf/3sSPBIQqusM+xiorjqHxVBkk7qmLn3rTnd1jgnhpGpJlncIwRGz9r61H t5AUYXzDpYZJyuaEJp07ls1A+1f9x9na+/JF9bvvJo00zLzJyZ/EtrRdLQ0Z7IcI6O 5mmwEBBGFelmw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 08/32] x86/boot/e820: Print E820_TYPE_RAM entries as ... RAM entries Date: Thu, 15 May 2025 14:05:24 +0200 Message-ID: <20250515120549.2820541-9-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 'System RAM', like in /proc/iomem: BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] 1.9 GB System 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 7f600d32a999..0a324d0db60e 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(" System 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 Wed Dec 17 03:27:47 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 0CD392989A0 for ; Thu, 15 May 2025 12:06:27 +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=1747310788; cv=none; b=auBqjADogW2KlPqFChEI8bVadAGJkDQPowM7tfsQK2y9xfhxIkyzpO7d6iFLrohfNAfKMFNqSc9oKrlOv/zPJXy7Ky9XQUh5NT4PW8nJ15ykT4XU4wWrKUF+N1FmVJ9+KfzRV/nSQRNxXSeKe8LP6WOobRM4jr4ShR7RhbunaWI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310788; c=relaxed/simple; bh=UCbsGHgeAVdQRwSUcWCgwKGnxF0ODFn4ZhmD0uVukdk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EEoTDugMXEq5ZpvFmbOAE4DLEtUeWogqTvRb47fony7ye1oDJCSIn8S6zJhe0dfkXvDCRcmp50ggB67jpbMjoWlJF2Wsnp050GQFpUU3hsLX+6vNe5aKv2uUQWFJODewl+gjhRFuuXqxsDX7iy8XfKfs1sqH3yzAjGaYwdYXgts= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RSKJhPcp; 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="RSKJhPcp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71E35C4CEE7; Thu, 15 May 2025 12:06:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310787; bh=UCbsGHgeAVdQRwSUcWCgwKGnxF0ODFn4ZhmD0uVukdk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RSKJhPcpa0fwuCP03pcH3en5doWhK7bZVjjz2I5oy+ZKljVlJOfiBQRPcMPR6pqz9 NeMXPBop4iKv9aT/ZE4fT/3flrpaW4RSJ4hKP3L1BoA3OzjxdMRYzoowb11DyQuhle HKysW9Z3aw3eD3fxJJb5y4mydWLlmBRAq0ToQt3kLJDuFGqii5WWG7RbJ5HQW9wY3c nA0Jg7TU/7sWXZl00w12nFOIwLewuHhwl+VP6h2l7IlKo8zkFIioT9du/4mBgwXk11 KAVVMgee6VUGTW+cQHcAbFmR9B8bPKP1R004anHOfU+hO8+U0GfPJSaEUgxlKF1hu3 ao5kzugGtU0Jg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 09/32] x86/boot/e820: Call the PCI gap a 'gap' in the boot log printout Date: Thu, 15 May 2025 14:05:25 +0200 Message-ID: <20250515120549.2820541-10-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 0a324d0db60e..d85623c9ee1b 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 Wed Dec 17 03:27:47 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 1168529A9F5 for ; Thu, 15 May 2025 12:06: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=1747310791; cv=none; b=S86vr3NOeX9YRfA4ezzuRcsqx1kDoNLALFnqrS+c1KRvVEKS/ULZkIK45cqKtH8XjbG3h/OrNBK/IVj/7IuDkWGQFBCzteiuvTt3Xyne1MgKhfq6hFBmyisX4B3Nf3duu7xFwfbgC/uRNLav2LXYYi3FHhFhSMxJ6jT1w9s21Ys= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310791; c=relaxed/simple; bh=W1E1N3ZODGKITdBep/9WVCTUKzob6ru3/jorkoGAU/0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rHugTkmwbJouk3djec+9IihPsvbL3BTwq0TLnnZUME6RnXtw9fcqv/olCS+XrtcYzspoOzz/VL3Gux+nOIOjFE2H6TV544iMOySTB5AX2kYCPZgOu+4Lnpp5IS/o6GPNGjWiUJb4nj1ei2PKoL8pY9eLELPE54oXG3VUApMrLDE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iNZsgyr6; 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="iNZsgyr6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4BE5C4CEE9; Thu, 15 May 2025 12:06:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310790; bh=W1E1N3ZODGKITdBep/9WVCTUKzob6ru3/jorkoGAU/0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iNZsgyr6+8NKQr+i9Rq/F5Oir1Eb4Y5dM08ToizdoSjba8nAwPDGgj2MBfnInRmgz y6CIdSbb/eNu7G0FQx+dIE7xwRteTGnH0TULAxi0XHuSp4b/Y7/ZtuFSpapoKtKC5P QSCl2+AfSdQ36Z2RqgQDV0PqehHf4lvwmTbjIVwaqY17rvQQ4zEgHl4N8krLLOVk93 89arT/MVgJtIg4egPRn/Z420oh57gVbado8iKEdsOqfP0yUoEw8VzdTUVx4iwCeRl+ FkKLRr/IV+S4QmYQ+ZaMlcLIuGebh+vEhT1tIDQgB6zulSqfaL8gHwB3v0Cta73e42 rnf8nUPLt3enQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 10/32] x86/boot/e820: Use 'u64' consistently instead of 'unsigned long long' Date: Thu, 15 May 2025 14:05:26 +0200 Message-ID: <20250515120549.2820541-11-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 d85623c9ee1b..ba957f2ef210 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 Wed Dec 17 03:27:47 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 EE5C7299934 for ; Thu, 15 May 2025 12:06: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=1747310796; cv=none; b=Tdf5cCgs+lDwQs7DiaSOxru+Qw5QYwN6nDSoQDYpwq0qR+m/Xx3bC9PrcrF1RHS6kRmnHT7NWmovYMqN/HrJoqNXSuMENXhpqm6pwDQlDztJneWWgYgiknFiUchQ/uCoYenInDESNvRcLmrfPxV5KxoqevN1V5uF+5bQJkqFYYQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310796; c=relaxed/simple; bh=zlz2LW2psILmMeSA56Usw5WtFYzlc2S3xQ0OTXXfHQU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HNmFhTS6EJRLBJIkW4NzcQg0CDBFIfr2y65h+ULkL8r+B+rBteQy2IGnU/NG4HShLXsM+tuMQveeDDbZRGfoiUlsngobJF3raIldTBHaq2SIUSIkTMz2jUyeJljgz969KARZf6Syi9x5+tsNC+ddrs6PCMQoE8ehjD5D5in/wFk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F/VRUt1r; 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="F/VRUt1r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68E12C4CEE7; Thu, 15 May 2025 12:06:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310794; bh=zlz2LW2psILmMeSA56Usw5WtFYzlc2S3xQ0OTXXfHQU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F/VRUt1r8NKxyYNJq97M8HdR5MSwiBdm39AHEGwF6hIIykV5/WfEeLov4RZKMTBeM S2byg+UGFgfOHjpjkTOdU02JMhTi6jKB0SG13WPRklPlIfKilLrqDL++I3OK0/ViKb iXSzZ7B8OnOAY9XQWHq8A9CePIi4mEQmTlfT7qLqj/ME6r1nBxOyOrajYCErnLNZBO Imwjp6LKIje//fqQ2MED96FMV57/sIiVWpVcQIPJOJRYFseItMDoO0IpfYdtPNvYku XAVHENkVlz3MLabgUAp45W+lsc9CfUMAt3PyrgP/Osi+6DDjAtU4nlvojupfjua6xT JMEbKHH6FuEww== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 11/32] x86/boot/e820: Remove pointless early_panic() indirection Date: Thu, 15 May 2025 14:05:27 +0200 Message-ID: <20250515120549.2820541-12-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 ba957f2ef210..5eb0849b492f 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 Wed Dec 17 03:27:47 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 7BF9D29AB00 for ; Thu, 15 May 2025 12:06:38 +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=1747310798; cv=none; b=KyF7cfp0QlnvAKnRWNY9hXrveAgslk8jpOm0p1wlT5u0CM9jQeQPA5vERrv0GpNCm72x8ABRAAMp+m9X62GwYvrHj56KqSle+9Uw20zLNCftP3xAS15ruq/UFI2SUbshT9PUMYAwmvj0CuSv6SkhhQJ9SBc381memoGDwrQvBvg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310798; c=relaxed/simple; bh=Emt/5AsShxloWJm8UunwsVoTyrwJrnPq3W90YUu3z/c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uNHm/ixgfAYGrbRHmUWFhQaNzl5Vv9rIwT57s+4KmPoJyaUwoNAEmGWIDEp94eHTcT8JFSomvWh1aENOiDWP41+0LV6l+xJrDBCVLZvBgKKw2N01oMdhJhr9OswyEkNmpKcv9VyOxJf7VckmERx8xHygxpk803NG5tfoJDCLiOg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nWox5GcK; 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="nWox5GcK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1850C4CEED; Thu, 15 May 2025 12:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310797; bh=Emt/5AsShxloWJm8UunwsVoTyrwJrnPq3W90YUu3z/c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nWox5GcKj24xtqlDh7dZBl1Q/0nnnLWh4M2zMSk4lQRZzfeNKGGyDZqD1ZlJrIkvC AWogWdCDjGNhywAK7Kc/qnmhoNMXP2D8Hm7+8KNhUXiItJ4kSZFAiM9UGGkVqyvXWL /4zXnOaILQSFVV45JQm3CNyCJIqb3HJ7QYIVUGu507HxPlmHjVP9b44eX+lrGdudwS yRGCCIwkX3ZPVlguAsxvLsH+C0ZOLl9PAhrL/C2Iv4cVSh3XXG3QDua47+TVdyngP+ +ntGt23J1Ljiesd2xS9j5hPtXogib8Q08So7IMv/QoZSuNQxlrlDdfLOfC5yT6rVog kHKQtwZ5CiL7A== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 12/32] x86/boot/e820: Clean up confusing and self-contradictory verbiage around E820 related resource allocations Date: Thu, 15 May 2025 14:05:28 +0200 Message-ID: <20250515120549.2820541-13-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 5eb0849b492f..c9bb808c4888 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 Wed Dec 17 03:27:47 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 8F5DD29AB15 for ; Thu, 15 May 2025 12:06:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310801; cv=none; b=ai/9nDlEMniqA8qcGFFeUv8HTnaYVOGGlUGdcDiYX7Y8C7oJ53inGZ595EOm7VEc74Q6LvKxX/aO1QWvt5gb5g7tA8LmzMvtImaP5rVuFXLRLmkGJjo5RG2NmrwRou7mw84bKutgRgl6I7opQxeZj04VYweFTlDAZR9lp0deJZA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310801; c=relaxed/simple; bh=ouXUvj0RiTmifto5Z9N/f7U2etYpf1iuNLM8tYM3QuM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WipHHGr2fcNVkkpvYN8Gy7cxwhPgb28jeAcW43IIrwxOBDXg3haAUw7MLaZqHwbUQMTq7fm9DBY7Ge3M0dp3U3pNmpp44ptCIZuYQz93B6Pte7RDNge5Za1nkTCU10Lg8zhOYaKZgAgfDcWWNNZADNEsEoyR0JaXmxRZeGXsjkU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EEw//Dqw; 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="EEw//Dqw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6447EC4CEE9; Thu, 15 May 2025 12:06:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310801; bh=ouXUvj0RiTmifto5Z9N/f7U2etYpf1iuNLM8tYM3QuM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EEw//DqwMN9FLl5VqZqXRxe1kUlc4nj6oQchfDA4VYn1MmXrQLZkNrdOYTPhOaLxZ FI6r5JVxALwHX8z+D4oxP5aHbM6EQYSDEAmBDxrN6zaJAyxq4ZZGbL5N9uG3Gca/s6 DO4Ayk3op4tGHkHVUk0xpwLR6ONu77OMeGKf+3aVzjW2D/Q9QXiXM5Q6dnFrPlXXRR OHBEaM+V83fCg9e3K2WktOJr/vwl0zjEZJWEkwuINp21hbq+du4FZIIzDunv4s2jGo BNMKJugZNzh8Ody2lWTIpeCNPuftrQ2bX8bmSGEhtxa2/nFX3q2hwHLAPYpchfld1C Rjq383IH7C4fg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 13/32] x86/boot/e820: Improve e820_print_type() messages Date: Thu, 15 May 2025 14:05:29 +0200 Message-ID: <20250515120549.2820541-14-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 c9bb808c4888..6cb1e23dfc89 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(" System 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(" System 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 Wed Dec 17 03:27:47 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 6714A299954 for ; Thu, 15 May 2025 12:06: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=1747310805; cv=none; b=lk0AFoCmVszHfo8UTeI7bQtaVrSNDkTqKSQTHjqq8EEOy1nm0QVRTJ783ZBt7IVEYPPXt+jPHK0SNRjbAEcsebPohWE6N5K8eWseDiuzusNT+vGLGml6e2L5UynAs36DkMahWfNcicCgiwuQqBMjvI0PhLBmA/SnmvNtFB/uSqc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310805; c=relaxed/simple; bh=ehARHVg+NKSKLZPZhfgP0czrXJ6DMdIeOGpKIsrqthk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f/QXb5f8wq5XqA06WwYT03oPKM3GxSk6q5Hi6fgxjn1Z3ukWEpUj1b6/yI8yZwYcYs7/dBTgH7WD7LLBZkPbJxJl9eVG5YrJFtLqFM2A1B+nHs4mtnYE6ePlcUcDkVx/f1mS/Sdqq+qsgL+WDruQOQNTSjykPNPyOBeM4qeQbgU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hXZiV7oV; 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="hXZiV7oV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA482C4CEE7; Thu, 15 May 2025 12:06:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310804; bh=ehARHVg+NKSKLZPZhfgP0czrXJ6DMdIeOGpKIsrqthk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hXZiV7oVcgCes40cp1uhYZlbG23rpKcFNwukDBDBE3KDFUbtAdJq+ygSnHSy80iMu mHtWiU9p+8LBQ/Yp18RbGJYvQZqca4fjodzRJLvj65bj1afONWYcBOZnEAhIg5OhM7 1fQvA33TnmrYloeG90hQbNvo3GnIRkLw5krYKyGxg2kJmlqbJsBNeWLgEl0NMzXzqb 2SyNi+PI103IqKrkfvKwIsMZFsDl9L45EY9ZnPACnQPTGXpEhAqT0A8iVP1M5wo7aY nr1FTi0zpnACDimsETPLV1ZXo3YFQzPHpnYTM3SKzs9mFUdDXk96HcI2Yv8WfdQowL N55hCLjmZajeA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 14/32] x86/boot/e820: Clean up __e820__range_add() a bit Date: Thu, 15 May 2025 14:05:30 +0200 Message-ID: <20250515120549.2820541-15-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 6cb1e23dfc89..ba4e6e6bb0a5 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 Wed Dec 17 03:27:47 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 EB6AD29995B for ; Thu, 15 May 2025 12:06: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=1747310809; cv=none; b=Ww0lHZHufXFnTIJa0xGNnh24CYFlZ0IS/uGsw8jAtlx6pWzOAGXZDrVt8wUbF3zFAvrYVPQ/F6x3VnJqbtmYdH5mGkEipxNV/YJEYQTeSYdilCLE/VUJ6/u7bleeCRQYcKbFnn2ubrIKWgmRifmWup20iFW94yM3S6m4Q/sa2uI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310809; c=relaxed/simple; bh=RxpJ3+cdNa83Xvx4t3HxQG7xX7sZgpp20hKEHZVRxBQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DERzkELFB9TNW/OAiZZFLk06DM90uUNeWx3WDpWZz43oMRirHkjYGJwdubMtIfhMsmZ19Fe8gAUuQuFF7RcvMTQ9a4Gbf8uPKUElJ6r9HmETRuBa05axrs36oON1cLCU2cgVgNqjIC6tTfK9Xj3am+C8Savp6Ox4UN/4f6oUJws= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZsPIQ6Fj; 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="ZsPIQ6Fj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B906C4CEE9; Thu, 15 May 2025 12:06:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310808; bh=RxpJ3+cdNa83Xvx4t3HxQG7xX7sZgpp20hKEHZVRxBQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZsPIQ6FjeOgh/i+DcvxzGSCqDIp3LR69S56WmAscXsLywnFa67PD2OOu5FSRrhj3u 9PBX894ixKGarIR0aIUgXITnsWAQNSmZZ/rDhp5GGpUsy6VvuHo4y5z1yHksEQ9PyO 0FFfl13cIiqcmrH8QpnIL/k+atPlKDbkddCLZ7GEvDfsuxUYiiew9FAHo+cQ+HZZrW 3HNjFQ08VckK77HpKanWNnmOTfcaLVB3sAol7B6O/FR5t+CAEpcmOg1K4i35rTCmm3 Il2VVqNcOK8U0HMgw8z/Mj9aYCc38XIOghfj5+gNitdMbJvULRyYqmLNsTT+N8sada va5xEJ0AXkMvw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 15/32] x86/boot/e820: Clean up __refdata use a bit Date: Thu, 15 May 2025 14:05:31 +0200 Message-ID: <20250515120549.2820541-16-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 ba4e6e6bb0a5..bb48dcc8a8ee 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 Wed Dec 17 03:27:47 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 0330E29ACF0 for ; Thu, 15 May 2025 12:06: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=1747310812; cv=none; b=es9JwE8sLK/t0FtdYUKHUNsMLSeB2ULTxZc55VuvhXNGOyavWPuKyZPdBtrBpbxl/XQS82snrR9QkxHD1hdaeCuEXwBahXzrStfFQALQ1bGpTBEhQRDZd70h63K3Du+QCOIAtwfM0ZPmnuMd6cFbNZKtBvUPu1M3P5fUp0zjCDc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310812; c=relaxed/simple; bh=mH6rXAYLLxg6om6slxhoJmUxxtp/x8k2lGBaR2l65Yo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RrcSPmYUmF0uhVJPksRK5iXAjry8pzGZy998dJzWljxkRm9YZZppl69qo6gi7E7sPriTARnIeymsrCosUJhSb9YZcHmMP/6bppZU7KD8UclJcrXyz+Fb9jXQzXj4hEbBIEIyAMCr/YSSeTT1WqNhSYLOEZ5W7ZFPRA7zXX7C7yQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=puCntqTD; 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="puCntqTD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4942C4CEE7; Thu, 15 May 2025 12:06:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310811; bh=mH6rXAYLLxg6om6slxhoJmUxxtp/x8k2lGBaR2l65Yo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=puCntqTDnLdCo8An1dOq/7tVtRLSWasPw96sAvFK2xlqSryZGtlBq8M/EkgQtj/KD xwwwz2/eynVZQ2FdndyTXd8muWileA2Dx8nuELCwnU4cN+g+kPBSCFVyF1NcIUGO97 ZMjRFoPTzSL+e3Eptgjq0ZnpSreUQStOKtR+E9LHy0eGIDaGUTypY2WWDlDhig+Tsf wgtC9ogZ6m+/OFDUtYu0LV6gHzYfZw7SC+BasnRD6ScwWB38oLnhAQreA85qT6MZfI L4Exnha0252aQPN78PF/i2oxc2ejLf+DrT7m1tcuJDzAf8VoJII1qEP1cTzmPW1Xtq qKFlMiRiu25ag== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 16/32] x86/boot/e820: Remove unnecessary header inclusions Date: Thu, 15 May 2025 14:05:32 +0200 Message-ID: <20250515120549.2820541-17-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 bb48dcc8a8ee..806d69ca09af 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 Wed Dec 17 03:27:47 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 785962989B8 for ; Thu, 15 May 2025 12:06: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=1747310815; cv=none; b=dNb7yoLIOexQBDrrZFiHKWy2W6x2ZtIC+A8xhBZ3a+8C8nvwxhvcTOr0fvybfoHGmDqYdTmxXhSrorEAq1p7/sow5tF9um/ge/uvncqXL8vJxTlCowi4J5iyBsHmiBfwErpEk6mN+VW3kcX2MuBSh5GGH5dnW7Y2NIBy7d5lfPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310815; c=relaxed/simple; bh=+613i6Qpv86CPta/JjqLEpcQ1Ri3M1t7l9cAcIhqYcg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bUMVlqpPvcNhkqjCoDdlTXRdS+nzSudynwvKnNHCwhI87QQDy6yPNpxw9MICC5i4yITJARL6yCnpWh08GGCSFTwXMoEidN9VSsaM9Iba4Rf2PERtF33TZkKzn+LSWIc1pFaJ3K9X3/4SBloKkTnfse/Ry2QA692ZZcUCKmLafFI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iglIpxEs; 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="iglIpxEs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55FA0C4CEE9; Thu, 15 May 2025 12:06:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310815; bh=+613i6Qpv86CPta/JjqLEpcQ1Ri3M1t7l9cAcIhqYcg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iglIpxEsa3+94XFLhgZw9jG49hqXkmFDQ9UdUSUGlnnAks3re3LUpPuI1mqrLCZZ0 r5nHeIKvLImLP94GfD9eameRVCaegp/vBshPyWP1FeWUcPt3UeG9oaTR9p7oQ8pmf0 5+39s0xyZpbKEt6Vw8Me1GFrSWShjR67LlXiMMxOIKVr5VT0aybdYEzNYv6NiD4mlP yZlyHLj3r2hnYZ5PzGBWrB7mSH5nfhVltvUAy9MNShkeew6iMQXolWYIV3M/yJz3Sn AcYm4DaGgbkRQ1iu1bXUPzNvBb7QFtglSE20f44gEyEDgHyTn+GWAMQzJ09FVsT03Y NbmuiGT4Roz/A== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 17/32] x86/boot/e820: Standardize e820 table index variable names under 'idx' Date: Thu, 15 May 2025 14:05:33 +0200 Message-ID: <20250515120549.2820541-18-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 806d69ca09af..3ee266673fee 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 Wed Dec 17 03:27:47 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 5833329B213 for ; Thu, 15 May 2025 12:06: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=1747310819; cv=none; b=K8OrmE2jnHDw+HcUl+lJPJ9q2fmgD8Cm4E1o0UWuvLWS9D6AckvIxySG1SO0GK8fz9x5YGwMhU8KAfJuAv6V2oxYDs+lQdkXAkxz1Wsym8ZthnlVB1j6ZPiBu+SYyKqf0aJKNbm8h6vOKJ0Yze2JDf3iWVJDpD+YfQo8P+xE6eE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310819; c=relaxed/simple; bh=SSOpkzVQJ+Gun4Vf24Yh+HZva+MfCX/aj4fVSd7bon4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SxiUMbQqJhzg5DVeNITgyaIw5WPTKLuvd4Bs7Eb31/2gsZP3Q2Df0w83iSX82ek2hGZKOYKvv3YHzlZJnfPJIADz/P4PAFtZpoRZtU/40npHHQglEKLBMKPI2cR+btRRXHostEsIgi55G3Z+Lqr8yv3LZrY9OjDZua3oZPzUWKo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FlqhiA/l; 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="FlqhiA/l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF1A0C4CEEF; Thu, 15 May 2025 12:06:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310818; bh=SSOpkzVQJ+Gun4Vf24Yh+HZva+MfCX/aj4fVSd7bon4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FlqhiA/lkcZP4k8rSiDbq5wirhDzhDCbTEpPh9FLoBEyy1H1eXNePrWU2ueZrsCL8 A7ztdskv0eLeZDe4zzEbfX+vBL0DivHkvhxvRGsf36pDyYGl+npWQPynGX8pIkL8/n QqB8a1GpD6LliVGHqo+6P4oAVikkOEGrm4I9C97Qmb6UKmsCJPnJQIROV58e/EP2Yi zX9mxqFM9vbls0/F2CxwiLCCzBXxqxznxJ1XQ1XRyOLvxtBwvaG0cqxlYtG4JAW2fj 843MhGXsBrBAeM2Yqodp8jcWbekcw2Xw+EQBggO7JF5ppi/8KpQWlcTvIC8wUqK5Gw ves1TsxVVAFEQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 18/32] x86/boot/e820: Standardize e820 table index variable types under 'u32' Date: Thu, 15 May 2025 14:05:34 +0200 Message-ID: <20250515120549.2820541-19-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 3ee266673fee..ee8b56605e4a 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 Wed Dec 17 03:27:47 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 78C0D29B760 for ; Thu, 15 May 2025 12:07: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=1747310822; cv=none; b=P1HQdWgH0gGLQL/67ma9IXX56olTLVWoho4wz7y2gM4sCcUdIHJcfU+KhfTaLeRHM8pFeRc5PTuCKsn6/0wyX/tQj/mbHj/wB7vrvJIbhn+sJfaHm2tkhkaAsoq7uS43OCnrBTzzoluI8x1sxHokaw3Tfxdj3AQinwXnzPigUnc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310822; c=relaxed/simple; bh=Byaj85c16GdgkFY1HUTUudSVyNy63/4LKMI9cvomcnQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nTRpYh1XeMTmHkmmulz2DP61zd0FggIkC+RP+mMcBRZLT76b0C341qtpYQD4Ee32HPpEpt48yiu7KN0hdElYKgrrP9WcppdDWZZqeN45CzdBpMitrCYvaJJj0Sim1CPUaR+EYgJdraF3B67V78n47Ydgjj/5LIMa41Hd+HGqq3U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hpObGgcw; 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="hpObGgcw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51BA0C4CEE7; Thu, 15 May 2025 12:06:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310822; bh=Byaj85c16GdgkFY1HUTUudSVyNy63/4LKMI9cvomcnQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hpObGgcw7Mx2/TW6pBopbiplas/yFkJ9uzisA6RY2F3NjnCDqqpwjVdG0yGM0ykjW bFGIkrptS1fo0XVv6pbv5zU+Jw8iqctW+vQq1poGADDBZBYKPPuFZmd0U1laVeQN4m PBfQ+ImeK772sLpsvCvLYfLjufRgjqYb+eEs9pT9k0I0foEZNWcVPC1kOf4EAehpmy R/5NgMoWSoitL07XHrF74OIQPHghp/Y46ndAi5Tp1ZTd9idfU790uWdd0i8UaR3rdr TjUtZp8K/kQSpPAvtrJvDaAUqi3in8hy2PCqAUDoXVCfP7xVIeC396TAn+8OPmEPP2 zxcnlcV4WUMyA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 19/32] x86/boot/e820: Change struct e820_table::nr_entries type from __u32 to u32 Date: Thu, 15 May 2025 14:05:35 +0200 Message-ID: <20250515120549.2820541-20-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 Wed Dec 17 03:27:47 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 53BD2298CAD for ; Thu, 15 May 2025 12:07: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=1747310827; cv=none; b=rTrsPRIzlbJsSSSMNij1/nuw8lm6VGOljnkis99/bpBbXPPKzO3X2o+btk8Wxpfxm2lAT3dqVofiLIdl1iRW8UG0gxWl0x8i8M5abzfr1Xeke1wrcMY2OXmNDtaeVgMtoNCGM+xBMWdDPyFDJyeZ57ZrhDAb2S9ucxqINKqQZ1o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310827; c=relaxed/simple; bh=MlUQf1NQ7gX+mFF9JkdSt8ETIhb2gycIemf5SZNgLyg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=i+957oAqFTCsqB035RmKLaMnst9SeRsmA5BeLyuX5tLHBkFLRmbqr4W1U6juTsQuwXv6JsfqvapnHDstCGKsHAOFqBuo3pGysWGbewgmj3kjzrZ6aZqyFZKsEpLvu9xzIkwBJXEExROD4DWFxBjr4GOZliJvxSVnPZwOzjulaqU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SAUQaRRV; 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="SAUQaRRV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CACC8C4CEE7; Thu, 15 May 2025 12:07:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310825; bh=MlUQf1NQ7gX+mFF9JkdSt8ETIhb2gycIemf5SZNgLyg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SAUQaRRVmFlsw0OHMWuVjA1o+1mFH67dZm56X7pm09P3Oe2Eo0SkN8bRhsyADrj6+ 9HPvy3m/xkSJ0/kDhkbJrUuG+e826ECGVh+DlnM2Y1I6aPk7nvr9JGt2Y0KL1PsIPa FPJoTp2H66M4rE3FjoWtIAbtRCfZTAVbgovtAd3zU4fgFmy1hfG0Og1AW8oA/Ztijt jJFg4H1FVsCTrHTzkfMm2jkW8JRXigm9r0AL+2PzUvBJ4/2eWBcCbchHAFki5tY5pz kf/D3Uu/unQ0v/HwJ91qdWrZmiB0+JmbXOhZju6iQJm46nBWSeiuLP2/C3FOzp+Xiv dX6c9nPA9UcGw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 20/32] x86/boot/e820: Clean up e820__setup_pci_gap()/e820_search_gap() a bit Date: Thu, 15 May 2025 14:05:36 +0200 Message-ID: <20250515120549.2820541-21-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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" Apply misc cleanups: - Use a bit more readable variable names, we haven't run out of underscore characters in the kernel yet. - s/0x400000/SZ_4M - s/1024*1024/SZ_1M Suggested-by: Andy Shevchenko Signed-off-by: Ingo Molnar 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 ee8b56605e4a..d00ca2dd20b7 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 SZ_4M; + 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) + SZ_1M; 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 Wed Dec 17 03:27:47 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 DD0F029B792 for ; Thu, 15 May 2025 12:07: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=1747310829; cv=none; b=LCsqUUCeIjlQGPF4CVa+V5iSK7z+Y6henjovuXWoOO16QlkNmrEGRhKFRu404QOIgrzDltbSVDgObWtRouSTqE9H7lR2J27EUiqXrjh7Ia0qEK1ws/Ct2e6LtcDEsd21SiBgKzG5dnXfoq1ji/XUXmXpFX7x3fdHAvX+SzO1+XI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310829; c=relaxed/simple; bh=0bVLepRmSf4x42XCWjSkvidF6vxwDbzkDvwqQdZ6Yjo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EkUNIa6VsLFCgORyk48eyZlg8U1QUHtOmXHk2A7enW3vRErSY2UVLg/0qH3cL1p9t0r4q+FxWsrNtgl7s4pDSLbHzoMYygg3CK0BZ6UcJc8S0TSDYvds7LrH7sxHRWgkTZTI7GmTycKDpsBS34wEy13hoNlIt7EH/42qDNZ5NB0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Cmz/Dffe; 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="Cmz/Dffe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CBE2C4CEE9; Thu, 15 May 2025 12:07:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310829; bh=0bVLepRmSf4x42XCWjSkvidF6vxwDbzkDvwqQdZ6Yjo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Cmz/DffeKKpKIicL52xP7tQz7bi5fjZsxgdh2m9n4LvmmEeDwm8/fZFfqp3Ocqrnc fT+hKgwkwJAa6TH8mYlx1fPa/65KpIGMote3OZTIz4AaWrkv73yWg2eMeeT8Ujdbyt iPWfUMto5FmZVw79MLvUOU8RCa4bD5QgnGebGA3RDAqbYsG9dnOrE7hkfP5kskb3Pl zDpLDO4Y9PzDgFryVRJQzR9i7xrvYXY3VCWvpQAz9FesGPnbwklVbzuyhDrQw7ns04 QMORKDrDf9VgjzOetR4HGQMFCHaqE6MHdCxsWlnMnSiQVzQUaAk5El16IsfpgufkME WNfFzvt7fUS3Q== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 21/32] x86/boot/e820: Change e820_search_gap() to search for the highest-address PCI gap Date: Thu, 15 May 2025 14:05:37 +0200 Message-ID: <20250515120549.2820541-22-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 d00ca2dd20b7..b2e2ada50adb 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 Wed Dec 17 03:27:47 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 E3F1529B79A for ; Thu, 15 May 2025 12:07: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=1747310833; cv=none; b=QDe6CRpjy6QnWhH6iVRhjBFfI3+SkZ2yqeulUt+q+ie2oVEvNGDpsrs0o9boJXL/uEfqwCvCX/SXb61Qyl+yEBjjhW+hB+E5ETtgQNkzToyN3Mc9mLCHcF6eNFMldinGgOIhQRpzdCZzYLz6SsTSX1i7nPaD5HCOwnLgfzO8a8w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310833; c=relaxed/simple; bh=6SLHwAUM+btkcB2mBfsCr4BZVFt3PSCOic7YPAKPi2Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JUgzQNtHg+2tgPmFzfjrzZ8Zx+3t2Nz17FRPDSUEUNoizq5b+Dd5Eoi7YrjjC6Z9ECKYcVzuBLLFgy2qci2u+qSXjh4KUbSQyelsx4nABw2vPwzQkafU6S593bjBMCqdwkG5EG1dFz0mksR0k4SJQ+lRI6wdCatc/FXLKkamGlU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YSiiALgF; 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="YSiiALgF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3763C4CEED; Thu, 15 May 2025 12:07:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310832; bh=6SLHwAUM+btkcB2mBfsCr4BZVFt3PSCOic7YPAKPi2Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YSiiALgFOU0cuDpivGfNQorZvkaDRiXlauriTFhJLBI3IxW8Puj99quPban2aT6b2 RIKrEDr/XISSUXc2WubCkqzEOqEpXZQOKxB1rnezIwGJN5JGAjWuP5Lyn+v7A+b0Kq ImSNi0kzWc0ay1ozx5Ofg5ef9Hr1JFO/L+f4ut8yCbp1V8hGRmRzODO8lp7j7MlO5W hFn96g54qo8eBxR51Do4RSWpaSNo3Y8HF/2RNtMG/67D2jNLaKMMVEEiLD2TaxDC8t 43gtvQ5xXC9gj75h/6vF5ZK+oIgqqcJNxi/JnNMU4lz0VW89SeFFp/JlxFPELaTIIU Sob++HOsJSpsw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 22/32] x86/boot/e820: Rename gap_start/gap_size to max_gap_start/max_gap_start in e820_search_gap() et al Date: Thu, 15 May 2025 14:05:38 +0200 Message-ID: <20250515120549.2820541-23-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 b2e2ada50adb..1eb5afbdd9e6 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 SZ_4M; - found =3D e820_search_gap(&gap_start, &gap_size); + max_gap_size =3D SZ_4M; + 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) + SZ_1M; + max_gap_start =3D (max_pfn << PAGE_SHIFT) + SZ_1M; 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 Wed Dec 17 03:27:47 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 D0AAA29B79A for ; Thu, 15 May 2025 12:07:16 +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=1747310837; cv=none; b=dZBrD2fyqAlG7dM5/Jb2DIo2T12szVVNupDsOQOVnaLeaFDL0kD8CFkFVb07lSudJAPu4lWqXR7VmwzXq6AlgePYOSMOrmzi07BQ99T8dsxYmP8OINcx9ST2GTiCY67YmmDt8VUD6goCa7ZbhCINehJBS4x3dD1kIj/zfJ5jWaE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310837; c=relaxed/simple; bh=30qS1W/bA7jqRTQTKy+0M1mASu4o7tTdLTRb9GWcrrU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AqNzk/IETe9VDCm9nyJboU1I4niBDI7SGv47lVTo1eEHbc6mzctaGFC2GngvCUmiSSaYJn+Uw3DTLEax3s4PMRiyFEMOoEqq5YLt2oobRS6dJreY3ZV0Sa19jYyk2yrATxF8pXgiUJ3qcDnFEL6P4eWil0OI7FUicmJGagF9y1I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eaM9ORjB; 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="eaM9ORjB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44966C4CEE7; Thu, 15 May 2025 12:07:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310836; bh=30qS1W/bA7jqRTQTKy+0M1mASu4o7tTdLTRb9GWcrrU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eaM9ORjBHW8neFghs9VzrnN07mZy4sw0pHNs88XQeD0Dm+bdT5VviOTO8kRJ12zoy mGW35JivDb+0BVVR/rhvAB2dl20MNxDIj3QyQAxv2XEDD0sVgPnG8jA0bstfoa21/P EeLrXMG8N12TaSVt5eQKKWNgvahVJz2JVaREA7ForGWfhldB8pHJGQbXAnWw+7cFgN OL2FL50CywS8j1lKg1nqO5h9Lq2V3bJ1uVxjPo/XmBjsksFHgXCLk3z2Xmqu+tD/Qn 2tzL8fOBePeqJa0LuL2uc5TxOcgHCpVt4Szgve3zGEj5MW5TELKkMcmyC41TmOckD4 zsdb5Bl9KHhhw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 23/32] x86/boot/e820: Simplify & clarify __e820__range_add() a bit Date: Thu, 15 May 2025 14:05:39 +0200 Message-ID: <20250515120549.2820541-24-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 1eb5afbdd9e6..7c27661d0e41 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 Wed Dec 17 03:27:47 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 D988D29B8E6 for ; Thu, 15 May 2025 12:07:19 +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=1747310839; cv=none; b=LJXMu/IOqLtcMOCra1GNcfco1gvFBLO9zCvrKuS0T2c3PzRxLfNOrATeeEksvEPj7QNJ4+HjLoaQW8o3oiSEbUHoXxx7Tq9FQy7874Ekrf0JSMJnETqfw9fcNZYw8p2jdMKIZtTiCEzqD8ZDigR/zb9ymSlkISe2NitoODzO5iY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310839; c=relaxed/simple; bh=Y7uskAA1BCAYuTKKXerazkurQXVkOObkZARhKUv4AMI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JDMhPuiybrGVHFtVsuVRuZODdKJevmNIeu4WOXelY4ekP8ysWXIg+joyfn+lU1JPmOAPBimdvj8Dlmw7fkylsjrUJYIPIjfQWs80/Hu+I4WIHR/Sx09zJHfBeOzOksyX1Mt0Mb1b0yu9d2iiMa5t015vkm4H+yCxWPbCcgwhW7k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f3quujlr; 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="f3quujlr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8D3BC4CEE9; Thu, 15 May 2025 12:07:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310839; bh=Y7uskAA1BCAYuTKKXerazkurQXVkOObkZARhKUv4AMI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f3quujlrZKTcej8578ktRt3q98W+Ibphr3hLd8vIuBp51VwtmQbH7tDc6YvmhvAPd fly7H3srMAdUHb5OJLnny3XiUbWM0R20dr1EHzKPfaxno4R2mGpQlvTPc0BuaJZ8qS SempYpdRIO5yH4cZYg/KQGg7zzAEgmOglTVqmA5iUYFr4VctHbfswEEMaVhGSmo175 smj/SlI1j0jiCWGgrw/JAiewjYdVPsl6o0/ucYoQs0TmEG76Uyqi+GFaM+fR7eI1+1 ISxhgTk10j1s31pMHbFMLXLbGtYQI8xoTy0RSd9u+6xMEQQJP22LzhZED9dEu/0Yli cn0Q0S7YJGNUg== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 24/32] x86/boot/e820: Standardize __init/__initdata tag placement Date: Thu, 15 May 2025 14:05:40 +0200 Message-ID: <20250515120549.2820541-25-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 7c27661d0e41..447f8bbb77b8 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(" System 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 Wed Dec 17 03:27:47 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 5F71529B8FC for ; Thu, 15 May 2025 12:07: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=1747310843; cv=none; b=gPVFkFAlDQsSZmI7NPNo9qvMlrliwHJBipTIgJjtNe4lqdjRaCdnpKbOG8mczvj99CecWtiDC0gXtFLxwdKBSLULzLG5g9ObfEx7+5B6CLrayxq9lDhUWAKApn7rpjoLJWB4aKQjXxktinvfPrMrMVVjVpP0S2T0d+7aq6jjXQ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310843; c=relaxed/simple; bh=DxdXzcctVDPHawDRTusyFP68wroNBy7P8vzDdxb6Rss=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ElchncxG/s/YygmTHaMrUWXcxhpI1oqyYUZoPLxNNmSJ0mG1lVAIj2TZiE3VWpQ4D/Ie5hHk1Cg7Be6+2Smv/PnzWlX5aUANtfM57ptyTE9UCtH7DlbGjD4il0iDr+acsYUjScQRXmievOrl2Yfg9LzYOnogKOaIllsFTYLct1I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=air0cQzs; 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="air0cQzs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39F08C4CEE7; Thu, 15 May 2025 12:07:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310843; bh=DxdXzcctVDPHawDRTusyFP68wroNBy7P8vzDdxb6Rss=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=air0cQzsw2ix/Xr0SDm6fxPDzNB5cu/NBea58XceGh6zwajwJ37a4WXuN40KLFX1T 9o4JsYp8N4681T3OZtLU6Y0ykXy11e61QY7IXpmp/oxOALEcLkGdmhSfARSgcOO3mK TlkWSjul6IAtsrRcS7IsXf7CkyDsIpwGYuxv75FBPZhz9aBQdrwVw0Aa/g7O3OCLUp yR64i3Ey36L6GtFHhiXPo+Ow6iWDycq5wSRd6zwyGmwkrTyfyuqgNczEtbXHF/Uu7p TNY/V4PNuU1Uyc2XVkabegv7LAajbyDKnAMbXaEFjKQNyBzSlfsIJBzw1N9Mi+JOMa rhjkhTEPTHLwQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 25/32] x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables Date: Thu, 15 May 2025 14:05:41 +0200 Message-ID: <20250515120549.2820541-26-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 447f8bbb77b8..22bfcad7b723 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 Wed Dec 17 03:27:47 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 4321529A311 for ; Thu, 15 May 2025 12:07: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=1747310847; cv=none; b=RuYcc8kCSre6lDEIj8Ud0ngSO5RqQz6+REk/I70LMryTxUKuWEOuSiqVAD4/9ULGUkQ435QYRP68N7hIGUCuZIlsPh8Bly9oEH2uqyhWP/f0AIx86a6ODX3+G5Ou90X8NPBxroADbwof5TFNBiLPHG8GA2g65ZEoFG+t+iDqwIQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310847; c=relaxed/simple; bh=RpiPBoEFrgVjyePw9jzNJG3wRbbb0PIjPyOlwIFuRd0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UCawVLzmH6ulzl4ZelvvwbGhTN7sOYTlrlGdymw8ccdXyhnEnvIzDCgcBPl/fE2PQRbBlKO/Q7DTR8XcZNSyU5N19yF91UaHAd1/S0UoNBfIlSOZT7I5NiCS9mV/R0oi2eXW9LcnngubpDAPaTFSpImw3/toUyANh4F7EukdyM0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BIR8RAPs; 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="BIR8RAPs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B34F3C4CEE7; Thu, 15 May 2025 12:07:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310846; bh=RpiPBoEFrgVjyePw9jzNJG3wRbbb0PIjPyOlwIFuRd0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BIR8RAPsRAuwPe+4Hp0cQ5p+4RIA1YWkH+D/94WIb9noEaOYYVx235Y+EF087c4M+ 35tEkG0ZbRBkKWkp544N0GQKEeguJnFRDFfAynjrWKbPwTYy2Yk3YA4FTTA7BNXj0K 5nYHayJlKWpAdFqxQiTzItlDMs4aoN09PqTkI9GPnzqFMyWHwEu/DKk6VT4+hlALwj 4AlFM1UPynj1C2S21CKzwAEuMbU/PVV2kM29Ebk/McIyBm67seJ3B5oUOLo5/SxSuR iuqIjyCaHZxYQpWVDzzCwJSEVwHthqoaIW1jG+lWQYzG/89ddlPobGH2lkx9hKlFNF Z8+fPgMc8bg6w== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 26/32] x86/boot/e820: Remove e820__range_remove()'s unused return parameter Date: Thu, 15 May 2025 14:05:42 +0200 Message-ID: <20250515120549.2820541-27-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 22bfcad7b723..0fc77ab72c5f 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 Wed Dec 17 03:27:47 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 B877629A311 for ; Thu, 15 May 2025 12:07:30 +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=1747310850; cv=none; b=U0m5+6kbqv0inKMBJn1L77tGdEzOWDcEE7NsDMeBLBOF1hdu/2/6NDa1+6VORaGRbR8f7l2ew5SYOYLEQvLeLSEbAJ6Yw9YutqGG4BjSb5v12RAcrZWhmiDEhrqaVbWveO4HhIXT9cc9Ukvq8sTIT+TpZTfptca3OwF2i5M+Mik= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310850; c=relaxed/simple; bh=WGx/wVMyN1mwQ5Wl4n4+val1Ddn9GH3N8wmYMPoD6kg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FAnfAjxrlAlTlgb0serjzJvmlxe7cG5NC+lm3oJI3iBZyPhLd6BycQRrKwir27i+DPx7al2Ng4sUyMWxJ50U/ZWlSCycUxfvBs4SsVawEh5o+ABDaLydl7Z+c73eIPP0yeHGvWMOHv1jrjwxKJ9nJV5oVlFp8yahOtn7a0qiyLQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r8KHsPJg; 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="r8KHsPJg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34964C4CEEF; Thu, 15 May 2025 12:07:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310850; bh=WGx/wVMyN1mwQ5Wl4n4+val1Ddn9GH3N8wmYMPoD6kg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r8KHsPJge9yWMHPROuqaizU6K1Y4zwQ6juA2Tgx931OLZyDi59ly1vn1OMRWmEYW8 MYEj6IWHRB6w5gYXAlRK+vvvjd7IA9xIOdauurGitnE6oHcN+fPDuRQ4bn17YMMJAu kKfXw9NgQS0k83JFxi2M/Kfq+2avoiO/tpG7tQn3Mq3Y+8n97rbbqrRHKp5iicj+gE pdA9NIdKIMZO+Ti4XYY6WaBCXphggGLqxJDKDY0c1V//io6vhtYdbYI/xHh1+NqKFV 26LlEVCkMAZm4idzPStao2YIIlfo3/6ufWJOBWrDfDfWHTzcfEtn7mpQKRvcL6nmXA 2wCjgVxfmICTw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 27/32] x86/boot/e820: Simplify the e820__range_remove() API Date: Thu, 15 May 2025 14:05:43 +0200 Message-ID: <20250515120549.2820541-28-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 0fc77ab72c5f..0d7e9794cd52 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 f40dffc3e014..72ac61c58ec8 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -732,7 +732,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); } @@ -754,7 +754,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 Wed Dec 17 03:27:47 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 3B05929C35B for ; Thu, 15 May 2025 12:07:33 +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=1747310854; cv=none; b=PhIkaMJElULPVRM5Oi3s5McdRdbNGKMtCjY9blOocIe8XobScwf6thBOnMI0wfZiNMUPaLDsHfFAwYgTpuqbgpIbFPricOgyB0aDV6i2mUDtdSfOx/H24Zofn8RdFPY8F85xragv+S0719GaA8mabfIG/63Fj08M8+YDK0nN7mg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310854; c=relaxed/simple; bh=VgVnHh1c7rhPJCchELKiTUN2OXkQW1yRKPkHQDPQf7w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c/+Zt2lwO1NM/AwJgsvPCjEa+XDUZC5RzfrzOY9Av7MhBv9RUrDzhkDTCYaKc+nWd9qqEROYSIH/LRKsqZfQJW4bmJDbHjkEOrUXR7XD+nP2CF/K5rMDZqzVUuHmpHLhOIw1I5Lj89MaA4wUp94/rZDnAiPYHFGnU7/nGIyyTAo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R5F33Esq; 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="R5F33Esq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE331C4CEE7; Thu, 15 May 2025 12:07:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310853; bh=VgVnHh1c7rhPJCchELKiTUN2OXkQW1yRKPkHQDPQf7w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R5F33EsqdUTJ9oWJtElxMkSAN+Ev8+STh1paLnnMLOB80n/X36ukMfuEiLj9Oo3OR m425Ktoic8wCzRNnN9C8Ag9Bedd4sjA1PMD6x7MKPAMNT4jf6NIhAFAPDquuGU1/LA pVirEuhctiO8HBfs6PkXlulTHv2iZkHysik726D9b8Y5zPDIM7KdLO6+yqDUc+V443 X5DzJwKhT8RkXGHZNPUkRz8TvgK7vHa+GYtdBWKzsLj4WNmzls6VA72oL57NSoV/UV K85+/vI1QrxgxwwO+U4hdadvMBMseR/tDg7xCJfo1yBfy64u84ntDgaBtBqIaePahw hrVWOXPutbQww== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 28/32] x86/boot/e820: Make sure e820_search_gap() finds all gaps Date: Thu, 15 May 2025 14:05:44 +0200 Message-ID: <20250515120549.2820541-29-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 0d7e9794cd52..5260ce6ad466 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 SZ_4M; 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 Wed Dec 17 03:27:47 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 5234829CB37 for ; Thu, 15 May 2025 12:07: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=1747310857; cv=none; b=jgjyRGcT4nB8vP+QqFDvxr36wvPVd0NfpX8Rsj48onBekjhRDW4EgZMJuxqCRxeaFNyuTFyomBD9kxACeMgr8hoCU6qaDMzRyzZ2GHHVInhXJclxZE88RI1Qa11CTeUdYFJu4DV0yp3BCnHlSGrtCxMdRcTWPUGrzkNu6UtTBZ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310857; c=relaxed/simple; bh=2SO7mjIYcRnFjMw60iUgeObaAMHDHhAGqTDKiGyMZyI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KKwID2MtirT/m2NIJOqc+6BCWlsTlWlL2Gr+vgw1qtdq1yXwDIhtr+6eqH391GCya/BfsMLrpBt8KqoeFnMdBs9a2LPbiivT/IKM/bw3LlX2XurX/2KxJin5jwpV3cRGBGn+0vSHPqrlKJ4PGdBcc5iPOaxH6C5Bm/4IBVcPbsg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sWTY4/Nh; 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="sWTY4/Nh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F7B4C4CEE9; Thu, 15 May 2025 12:07:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310857; bh=2SO7mjIYcRnFjMw60iUgeObaAMHDHhAGqTDKiGyMZyI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sWTY4/NhI/uWJr+dvofDTbvGPJpk+5SQXQ1/vxi2W09sh78e5QtAsOdpfBuphQNOp kiDL+MmAJKBla6N7qcDt6bHDgDSmkiqoOvYm/jfecS/o2scW+BUJ/Kf01hs2KI8tWl n8UZ6ozadzDMPjj2EV/MurzRYYNtfmYDNW/+BXEl+5Cf15CpZkSVMIhzt4KUFPsxf6 u3i29UNmxQI/jiX2qhWflJC/KYf1R2OwzyJS/YExdGurvnyw33mgqg2V8nniP8F7op ls0qQqrJE4xfvd15YlGYlrUgD4Xc2f6SZvUC1NLXong8rdGm8iK6mVc4nknNeDDugI K65QR5Da586cQ== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 29/32] x86/boot/e820: Introduce E820_TYPE_13 and treat it as a device region Date: Thu, 15 May 2025 14:05:45 +0200 Message-ID: <20250515120549.2820541-30-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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. Partially follow the ACPI spec and add a limited quirk for the E820_TYPE_13 type, and allow it to be claimed by device drivers (similarly to E820_TYPE_RESERVED). Don't change behavior for other unknown types. Reported-by: Paul Menzel Suggested-by: H. Peter Anvin 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 | 4 ++++ arch/x86/kernel/e820.c | 11 +++++++++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/e820/types.h b/arch/x86/include/asm/e820/= types.h index df12f7ee75d3..2430120c2528 100644 --- a/arch/x86/include/asm/e820/types.h +++ b/arch/x86/include/asm/e820/types.h @@ -27,6 +27,10 @@ enum e820_type { * 6 was assigned differently. Some time they will learn... ) */ E820_TYPE_PRAM =3D 12, + /* + * Certain firmware such as CoreBoot uses this type: + */ + E820_TYPE_13 =3D 13, =20 /* * Special-purpose memory is indicated to the system via the diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 5260ce6ad466..6c9c00ce8db9 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -1075,7 +1075,7 @@ __init static const char * e820_type_to_string(struct= e820_entry *entry) case E820_TYPE_PRAM: return "Persistent Memory (legacy)"; case E820_TYPE_PMEM: return "Persistent Memory"; case E820_TYPE_RESERVED: return "Reserved"; - case E820_TYPE_SOFT_RESERVED: return "Soft Reserved"; + case E820_TYPE_13: return "Type 13"; default: return "Unknown E820 type"; } } @@ -1090,6 +1090,7 @@ __init static unsigned long e820_type_to_iomem_type(s= truct e820_entry *entry) case E820_TYPE_PRAM: /* Fall-through: */ case E820_TYPE_PMEM: /* Fall-through: */ case E820_TYPE_RESERVED: /* Fall-through: */ + case E820_TYPE_13: /* Fall-through: */ case E820_TYPE_SOFT_RESERVED: /* Fall-through: */ default: return IORESOURCE_MEM; } @@ -1102,7 +1103,8 @@ __init static unsigned long e820_type_to_iores_desc(s= truct e820_entry *entry) case E820_TYPE_NVS: return IORES_DESC_ACPI_NV_STORAGE; case E820_TYPE_PMEM: return IORES_DESC_PERSISTENT_MEMORY; case E820_TYPE_PRAM: return IORES_DESC_PERSISTENT_MEMORY_LEGACY; - case E820_TYPE_RESERVED: return IORES_DESC_RESERVED; + case E820_TYPE_RESERVED: /* Fall-through: */ + case E820_TYPE_13: return IORES_DESC_RESERVED; case E820_TYPE_SOFT_RESERVED: return IORES_DESC_SOFT_RESERVED; case E820_TYPE_RAM: /* Fall-through: */ case E820_TYPE_UNUSABLE: /* Fall-through: */ @@ -1132,6 +1134,7 @@ __init static bool e820_device_region(enum e820_type = type, struct resource *res) */ switch (type) { case E820_TYPE_RESERVED: + case E820_TYPE_13: case E820_TYPE_SOFT_RESERVED: case E820_TYPE_PRAM: case E820_TYPE_PMEM: @@ -1140,6 +1143,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: + /* + * Unknown E820 types should be treated passively, here we + * don't allow them to be claimed by device drivers: + */ default: return false; } --=20 2.45.2 From nobody Wed Dec 17 03:27:47 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 CB6CB298CC3 for ; Thu, 15 May 2025 12:07: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=1747310860; cv=none; b=HoYv4goj3ASWHZbaU90mgavr8MrR8RLWbzfWdjKfMmpgLFqu73DOLtvzEwAUINRTvRfg2VP7HzVCfnzdLT0Y7wklXQ+cOFq0bnWhA67yd55w3XgO290tIIk6g3h/IYUjlA1ZvGGvlBTqTD9vH0DH6/mU56IBSxlhOzHus0qZOck= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310860; c=relaxed/simple; bh=RCTt96afOHkt8Yji9prljEO9r3H1m8J4rPEJXzCe2ZU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HhuymLfYYQLKEXAm/A0Tp51jlGsurokzLTcVfDWc45uTrtG8L/a9IKr1s4lw2Ynrr7UV92tvVPXPfJ8q/SlES8PxKM11AtVO7GQ4Lq63czmJbLJW49JRpuzsIlCAIlrpVDHIp7PqXDS4xFpsxIO+ioAi99xDlb6vb9HbMLFOnsk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hCcaECx6; 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="hCcaECx6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6635C4CEE7; Thu, 15 May 2025 12:07:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310860; bh=RCTt96afOHkt8Yji9prljEO9r3H1m8J4rPEJXzCe2ZU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hCcaECx6K5+wd1QH05dKxLJV1gFdwV9OtHNcCp/olfzFU6VOV2zQbMOEb0ii6vkiE /cYFCXn06aLj4lhzjWBr5eOsE9WkOmpEPCydFc8UgY+t5Th+W8Msaw7aTpvmDoaSS/ v+cyDoQhJT+Kugp8zuz2qhjIDgoaDwydfpZsZF/KI24CFSwkapMZWhR9GwExs/0mcq 1fH5+/Qy6I8NLlJolCbGmRJyRyXHh3aKD5KkDOJOrID1wBi9H17X9HU/WNFsMzf74z 24q+sE4aznsSL+wCWj8ZCOEZwjeuT6elM35ADdM71CDRRxsg2EH9Q5cWNGjecUcioZ oPN8Gty2q4A6g== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 30/32] x86/boot/e820: Change e820_type_to_string() to take a 'type' parameter Date: Thu, 15 May 2025 14:05:46 +0200 Message-ID: <20250515120549.2820541-31-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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" Simplify the e820_type_to_string() interface by changing it to take a 'enum e820_type type' parameter. This is going to allow the unification of the e820_type_to_string() and e820_print_type() functions. 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 | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 6c9c00ce8db9..fe3e078a4064 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -1065,9 +1065,9 @@ __init void e820__finish_early_params(void) } } =20 -__init static const char * e820_type_to_string(struct e820_entry *entry) +__init static const char * e820_type_to_string(enum e820_type type) { - switch (entry->type) { + switch (type) { case E820_TYPE_RAM: return "System RAM"; case E820_TYPE_ACPI: return "ACPI Tables"; case E820_TYPE_NVS: return "ACPI Non-volatile Storage"; @@ -1175,7 +1175,7 @@ __init void e820__reserve_resources(void) } res->start =3D entry->addr; res->end =3D end; - res->name =3D e820_type_to_string(entry); + res->name =3D e820_type_to_string(entry->type); res->flags =3D e820_type_to_iomem_type(entry); res->desc =3D e820_type_to_iores_desc(entry); =20 @@ -1195,7 +1195,7 @@ __init void e820__reserve_resources(void) 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)); + firmware_map_add_early(entry->addr, entry->addr + entry->size, e820_type= _to_string(entry->type)); } } =20 --=20 2.45.2 From nobody Wed Dec 17 03:27:47 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 4C18F29A9F2 for ; Thu, 15 May 2025 12:07:44 +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=1747310864; cv=none; b=Ic/Oj2XCyJ+4i+0i6MCZ1oRi0jqQhzkBZ8oC1uhUJwpLQ1Ps/oi28fpjhrqLttjB07v8eLcvPtX7AU/zICRdAY0jjkmGIqZg01Pc+RRKvYN/U5oBtNNEKc8qqTYRAVUzRyY8z2yiZnUfHTYNxRkmSqkLQ9iJEmJVeIRiB9WHdTc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310864; c=relaxed/simple; bh=ghtJHtFBHkIc5taAz+aoDzaw9paxhJ7baLkAGjJxESM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JsHhc/7n/eSsu0hDTcCkbMEP6MbubLBzmvOsPVnfD+VW7y3k006RqD5QLyYpqSWNlUyLDmVGRjXXPeBXl0VxfTWWLjRriOAOxVSHfRze4/L44T41ANb4Z2NOjf+l+6gpoSgIB2AnIWOeHFgnpPwpkeNEtlirvEs5ca5TNpElnTI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I6tsl2e0; 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="I6tsl2e0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B9CFC4CEE7; Thu, 15 May 2025 12:07:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310864; bh=ghtJHtFBHkIc5taAz+aoDzaw9paxhJ7baLkAGjJxESM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I6tsl2e0BtwlIABsxFkH4+de/9MkVa52951kTA98b0FvfP+kuK8APHvccYPEwxmRw ea2ammW/HYTQEOjMqpEqo1Gd6AbgR8avFp/0xCRykDbsKT9dJbLV3OZC9oQGqCsnwT YwmWUqSwgRLpED5Qqbp7/kG74wL4ft2YQw+shveyjRkKmPdGhlPwE/PGXBS0oSYs6k hDlOBawijZdFmc4ifsf2PaMN6Qd7xrZYqcxMKoUu7/M16gbYozPWKuCYIWzNfJWJyY 1sK2vSiWUuSVMydbZJyD44NCIh9nEbS2wZRSqERmlRxGX1GWgjPoiis9iQXgBMx24R jHENEjKq9MFLw== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 31/32] x86/boot/e820: Unify e820_print_type() and e820_type_to_string() Date: Thu, 15 May 2025 14:05:47 +0200 Message-ID: <20250515120549.2820541-32-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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 e820_type_to_string() to derive e820_print_type(), and unify the messages: - Don't Capitalize Words Within Sentences Randomly - Use 'Device reserved' instead of 'Reserved' Suggested-by: Mike Rapoport (Microsoft) Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds --- arch/x86/kernel/e820.c | 50 ++++++++++++++++++++--------------------------= ---- 1 file changed, 20 insertions(+), 30 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index fe3e078a4064..10c6e7dc72d7 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -68,6 +68,26 @@ unsigned long pci_mem_start =3D 0xaeedbabe; EXPORT_SYMBOL(pci_mem_start); #endif =20 +__init static const char * e820_type_to_string(enum e820_type type) +{ + switch (type) { + case E820_TYPE_RAM: return "System RAM"; + case E820_TYPE_ACPI: return "ACPI tables"; + case E820_TYPE_NVS: return "ACPI non-volatile storage"; + case E820_TYPE_UNUSABLE: return "Unusable memory"; + case E820_TYPE_PRAM: return "Persistent memory (legacy)"; + case E820_TYPE_PMEM: return "Persistent memory"; + case E820_TYPE_RESERVED: return "Device reserved"; + case E820_TYPE_13: return "Type 13"; + default: return "Unknown E820 type"; + } +} + +__init static void e820_print_type(enum e820_type type) +{ + pr_cont(" %s", e820_type_to_string(type)); +} + /* * This function checks if any part of the range is mapped * with type. @@ -186,21 +206,6 @@ __init void e820__range_add(u64 start, u64 size, enum = e820_type type) __e820__range_add(e820_table, start, size, type); } =20 -__init static void e820_print_type(enum e820_type type) -{ - switch (type) { - case E820_TYPE_RAM: pr_cont(" System 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 RAM (type %u)", type); break; - default: pr_cont(" type %u", type); break; - } -} - /* * Print out the size of a E820 region, in human-readable * fashion, going from KB, MB, GB to TB units. @@ -1065,21 +1070,6 @@ __init void e820__finish_early_params(void) } } =20 -__init static const char * e820_type_to_string(enum e820_type type) -{ - switch (type) { - case E820_TYPE_RAM: return "System RAM"; - case E820_TYPE_ACPI: return "ACPI Tables"; - case E820_TYPE_NVS: return "ACPI Non-volatile Storage"; - case E820_TYPE_UNUSABLE: return "Unusable memory"; - case E820_TYPE_PRAM: return "Persistent Memory (legacy)"; - case E820_TYPE_PMEM: return "Persistent Memory"; - case E820_TYPE_RESERVED: return "Reserved"; - case E820_TYPE_13: return "Type 13"; - default: return "Unknown E820 type"; - } -} - __init static unsigned long e820_type_to_iomem_type(struct e820_entry *ent= ry) { switch (entry->type) { --=20 2.45.2 From nobody Wed Dec 17 03:27:47 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 C670D29A9F2 for ; Thu, 15 May 2025 12:07:47 +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=1747310867; cv=none; b=DzJXl97BHb0iXzjTJhzJNqlE+tByTW224l93ebwoJSV8EnU+sFYQ2XEurbQDMTTxMvGOAqC0k2SIsjqazNU1+hax+RxBIgTBr000ZORxYOEhOLwP7kHPSU4yEVjrgWmsE6tct98z8w2titmdsVNthSyx6YvdQEW+JEQaMfDeY9E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747310867; c=relaxed/simple; bh=sGCEBmgaCgK4XJ/4Qqqaf2NGqfrh7owWZSkkh47w4Lg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b6WxVmdkaHe9qpkWB+jffgIuN1VE/ACEZ2Z1Q8G606oSnVsjrLMgFZXWSDBkcnH3hoynQmCAVUXAxDfO7u+8sZJ6uwZtTi1GG7SiG3uRB2k30vuYuVNT4m2deNfgvGAneRLV73CRUeNxtrnCuQp3kumLTnn8B3HpBOcB882H7FU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f5aoeI08; 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="f5aoeI08" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A19A3C4CEEF; Thu, 15 May 2025 12:07:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747310867; bh=sGCEBmgaCgK4XJ/4Qqqaf2NGqfrh7owWZSkkh47w4Lg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f5aoeI08UKyZnNhnSRI8bac4X8+UphK0F5S2UxU2vlUjUORQtW/tBrc1yibnEzcWm 6QLO88/J/StmMvEZbIGBqF2ftJCWG0c3QKC9hyBH62oqWd2nVzPMeSliHOfsrWrqoD PQXb6cthjX5upZVT40+tXPqYleaJVgBYpNlXSs9wIz1LYfzqaaj6i8lfjQFw44kVfZ qF0KO2ngy/WBcHp1eZSC6vlrssqIhGn5sxsuY5eW9zGNinqQfi/vpgOmn8sWlgmjZv rdoq6dhJ9E72g7tVrLMr/yPW8YCUVdGchE4iyxb0HU6dPsnYLJsclVjER4H4Q3QicT X22xaqoKFfHSA== From: Ingo Molnar To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andy Shevchenko , Arnd Bergmann , Borislav Petkov , Juergen Gross , "H . Peter Anvin" , Kees Cook , Linus Torvalds , Mike Rapoport , Paul Menzel , Peter Zijlstra , Thomas Gleixner , David Woodhouse Subject: [PATCH 32/32] x86/boot/e820: Move index increments outside accessors in e820__update_table() Date: Thu, 15 May 2025 14:05:48 +0200 Message-ID: <20250515120549.2820541-33-mingo@kernel.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250515120549.2820541-1-mingo@kernel.org> References: <20250515120549.2820541-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" This kind of code: change_point[chg_idx++]->entry =3D &entries[idx]; Can be a bit confusing to human readers, and GCC-15 started warning about these patterns. Move the index increment outside the accessor. Suggested-by: Andy Shevchenko Signed-off-by: Ingo Molnar 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, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 10c6e7dc72d7..afb312620c82 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -421,9 +421,11 @@ __init int e820__update_table(struct e820_table *table) 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]->entry =3D &entries[idx]; + chg_idx++; change_point[chg_idx]->addr =3D entries[idx].addr + entries[idx].size; - change_point[chg_idx++]->entry =3D &entries[idx]; + change_point[chg_idx]->entry =3D &entries[idx]; + chg_idx++; } } chg_nr =3D chg_idx; --=20 2.45.2