linux-kernel - Re: [TECH TOPIC] Reaching consensus on CONFIG

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <02b0f383-1c43-4eeb-a76f-830c2970b833@app.fastmail.com>
Date: Thu, 18 Sep 2025 15:12:46 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jason Gunthorpe" <jgg@...dia.com>
Cc: ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
 linux-mips@...r.kernel.org, linux-mm@...ck.org, imx@...ts.linux.dev,
 "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Richard Weinberger" <richard@....at>,
 "Lucas Stach" <l.stach@...gutronix.de>,
 "Linus Walleij" <linus.walleij@...aro.org>,
 "Geert Uytterhoeven" <geert+renesas@...der.be>,
 "Ankur Arora" <ankur.a.arora@...cle.com>,
 "David Hildenbrand" <david@...hat.com>,
 "Mike Rapoport" <rppt@...nel.org>,
 "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>,
 "Matthew Wilcox" <willy@...radead.org>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 "Vlastimil Babka" <vbabka@...e.cz>,
 "Suren Baghdasaryan" <surenb@...gle.com>,
 "Ira Weiny" <ira.weiny@...el.com>, "Nishanth Menon" <nm@...com>,
 Heiko Stübner <heiko@...ech.de>,
 "Alexander Sverdlin" <alexander.sverdlin@...il.com>,
 "Chester A. Unal" <chester.a.unal@...nc9.com>,
 "Sergio Paracuellos" <sergio.paracuellos@...il.com>,
 "Andreas Larsson" <andreas@...sler.com>
Subject: Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

On Wed, Sep 17, 2025, at 14:59, Jason Gunthorpe wrote:
> On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>
>> I'm still collecting information about which of the remaining highmem
>> users plan to keep updating their kernels and for what reason. 
>
> On this topic of removing some parts of highmem, can we say goodbye to
> kmap_high_get()? Only ARM uses it and only for
> !cache_is_vipt_nonaliasing() systems.

Good idea. I think we are almost there, just need to verify that
there is actually no impact for existing users. I already knew
that there is very little highmem usage on ARMv6 and earlier, but
I tried to recheck all platforms that might be affected:

* As you say (and contrary to what the code comments suggest),
  all ARMv7 and most ARMv6 systems have non-aliasing VIPT or
  PIPT caches, so kmap_high_get() does nothing, and we could
  just turn it off for those configurations.

* ARMv6 with aliasing VIPT caches exist but are fairly rare,
  and I think there are no ARMv6 machines left that actually
  use highmem. AST2500 is commonly used and has aliasing
  caches, but I only see machines with 512MB or less, and
  its aspeed_v5_defconfig enables CONFIG_SMP (for AST2600).
  OMAP2 and realview are in the same category but less
  important. imx3, s3c64xx and bcm2835 are non-aliasing
  (and don't have highmem either).

* VIVT caches are used on all ARMv5 and earlier, so removing
  kmap_high_get() would effectively break highmem these.
  Most ARMv5 use very small amounts of memory (<256M) in
  a single physical address range, so they are unaffected,
  we just have to go through the ones that are left.

* Intel IOP (armv5 xscale) certainly had highmem but was
  removed a while ago.

* Marvell mv78xx0 and kirkwood (armv5 pj1) were fairly
  powerful in 2008 and could support at least 1GB of RAM,
  but I only found one machine (OpenBlocks A7) that does
  this. It's unclear if anyone is still updating kernels
  on this machine, but they could /probably/ use
  VMSPLIT_3G_OPT if they do.

* Microchip SAM9x7 is the newest ARMv5 chip, clearly does
  get kernel updates, and the only one I can think of with
  DDR3 support, but seems to be limited to 256MB total memory.

* The Gemini (ARMv4) platform enabled highmem as part of
  commit c12d7e9fe9af ("ARM: defconfig: Update Gemini defconfig"),
  but I don't see why, as the machine cited there only has
  128MB of RAM in a contiguous chunk.

* A few ARMv4/v5 machines (omap1, davinci, ep93xx, clps71xx,
  sa1100, riscpc) used to select CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
  or SPARSEMEM, which would indicate that they might need
  highmem even for <1GB configurations if their memory banks are
  far apart in physical memory. I checked those and as far
  as I can tell, they are always within 768MB or less.

     Arnd