linux-kernel - [RFT PATCH] MIPS: Octeon: drop dependency on CONFIG_HOLES_IN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 18 Apr 2021 12:35:12 +0300
From:   Mike Rapoport <rppt@...nel.org>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc:     linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mike Rapoport <rppt@...ux.ibm.com>
Subject: [RFT PATCH] MIPS: Octeon: drop dependency on CONFIG_HOLES_IN_ZONE

From: Mike Rapoport <rppt@...ux.ibm.com>

CAVIUM_OCTEON_SOC configuration selects HOLES_IN_ZONE option to cope with
memory crashes that were happening in 2011.

This option effectively aliases pfn_valid_within() to pfn_valid() when
enabled and hardwires it to 1 when disabled. The check for
pfn_valid_within() is only relevant in case the memory map may have holes
or undefined struct page instances inside MAX_ORDER chunks.

Since 2011 memory management initialization in general and memory map
initialization particularly became much more robust so the check for
pfn_valid_within() is not required on Octeon even despite its, hmm, unusual
memory setup.

Remove the selection of HOLES_IN_ZONE by CAVIUM_OCTEON_SOC and drop the
HOLES_IN_ZONE configuration option entirely as Octeon was the only MIPS
platform to use it.

Signed-off-by: Mike Rapoport <rppt@...ux.ibm.com>
---

Hi,

I've tried to find why Octeon needed CONFIG_HOLES_IN_ZONE in the first
place, but there is nothing except the changelog in commit 465aaed0030b
("MIPS: Octeon: Select CONFIG_HOLES_IN_ZONE"):

  Current Octeon systems do in fact have holes in their memory zones.
  We need to select HOLES_IN_ZONE. If we do not, some memory configurations
  will result in crashes at boot time

Since then there were too many changes around memory management
initialization both in the generic mm and on the MIPS side to track what
exactly could case the crashes.

I'm pretty confident that HOLES_IN_ZONE is not required for Octeon systems
anymore and can be removed.

I'd really appreciate if somebody with access to an Octeon system could
test this patch.

 arch/mips/Kconfig | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..96b08cd3b442 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -990,7 +990,6 @@ config CAVIUM_OCTEON_SOC
 	select HAVE_PLAT_FW_INIT_CMDLINE
 	select HAVE_PLAT_MEMCPY
 	select ZONE_DMA32
-	select HOLES_IN_ZONE
 	select GPIOLIB
 	select USE_OF
 	select ARCH_SPARSEMEM_ENABLE
@@ -1226,9 +1225,6 @@ config HAVE_PLAT_MEMCPY
 config ISA_DMA_API
 	bool

-config HOLES_IN_ZONE
-	bool
-
 config SYS_SUPPORTS_RELOCATABLE
 	bool
 	help
-- 
2.28.0