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]
Message-Id: <20210418093512.668-1-rppt@kernel.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ