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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 3 May 2023 11:20:40 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     Justin Forbes <jforbes@...oraproject.org>,
        Will Deacon <will@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        jmforbes@...uxtx.org, Andrew Morton <akpm@...ux-foundation.org>,
        lkp@...el.com
Subject: Re: [PATCH] Revert arm64: drop ranges in definition of
 ARCH_FORCE_MAX_ORDER

On Tue, May 02, 2023 at 06:40:14PM +0100, Catalin Marinas wrote:
> On Tue, May 02, 2023 at 07:15:20PM +0300, Mike Rapoport wrote:
> > On Tue, May 02, 2023 at 03:07:41PM +0100, Catalin Marinas wrote:
> > > On Mon, May 01, 2023 at 04:24:38PM -0500, Justin Forbes wrote:
> > > 
> > > Regarding EXPERT, we could drop it and do like the other architectures
> > > but we'll have randconfig occasionally hitting weird values that won't
> > > build (like -1). Not sure EXPERT helps here.
> > 
> > AFAIU, randconfig does not randomize int values, it's probably random
> > people that do ;-)
> 
> https://lore.kernel.org/r/202303232149.Chh6KhiI-lkp@intel.com
> 
> with the randconfig here:
> 
> https://download.01.org/0day-ci/archive/20230323/202303232149.Chh6KhiI-lkp@intel.com/config

You may be right, I can't get my randconfig to set ARCH_FORCE_MAX_ORDER
to anything other than the default. Maybe the kernel test robot has its
own config randomisation (cc'ing lkp@...el.com).

If we don't care about about this randconfig, I'm fine do drop EXPERT
from current mainline, together with the 4K/16K pages condition. The
condition only made sense if we kept the ranges in since these were
configurable (no range for 64K).

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b1201d25a8a4..1867aba83ba3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1516,7 +1516,7 @@ config XEN
 # 16K |       27          |      14      |       13        |         11         |
 # 64K |       29          |      16      |       13        |         13         |
 config ARCH_FORCE_MAX_ORDER
-	int "Order of maximal physically contiguous allocations" if EXPERT && (ARM64_4K_PAGES || ARM64_16K_PAGES)
+	int "Order of maximal physically contiguous allocations"
 	default "13" if ARM64_64K_PAGES
 	default "11" if ARM64_16K_PAGES
 	default "10"

-- 
Catalin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ