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: <497308537.21756.1757513073548.JavaMail.zimbra@nod.at>
Date: Wed, 10 Sep 2025 16:04:33 +0200 (CEST)
From: Richard Weinberger <richard@....at>
To: Arnd Bergmann <arnd@...db.de>
Cc: ksummit <ksummit@...ts.linux.dev>, 
	linux-kernel <linux-kernel@...r.kernel.org>, 
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, 
	linuxppc-dev@...ts.ozlabs.org, 
	linux-mips <linux-mips@...r.kernel.org>, 
	linux-mm <linux-mm@...ck.org>, imx@...ts.linux.dev, 
	Christophe Leroy <christophe.leroy@...roup.eu>, 
	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>, vbabka <vbabka@...e.cz>, 
	Suren Baghdasaryan <surenb@...gle.com>, 
	Ira Weiny <ira.weiny@...el.com>, Nishanth Menon <nm@...com>, 
	heiko <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

Arnd,

----- Ursprüngliche Mail -----
> Von: "Arnd Bergmann" <arnd@...db.de>
> High memory is one of the least popular features of the Linux kernel.
> Added in 1999 for linux-2.3.16 to support large x86 machines, there
> are very few systems that still need it. I talked about about this
> recently at the Embedded Linux Conference on 32-bit systems [1][2][3]
> and there were a few older discussions before[4][5][6].
> 
> While removing a feature that is actively used is clearly a regression
> and not normally done, I expect removing highmem is going to happen
> at some point anyway when there are few enough users, but the question
> is when that time will be.
> 
> I'm still collecting information about which of the remaining highmem
> users plan to keep updating their kernels and for what reason. Some
> users obviously are alarmed about potentially losing this ability,
> so I hope to get a broad consensus on a specific timeline for how long
> we plan to support highmem in the page cache and to give every user
> sufficient time to migrate to a well-tested alternative setup if that
> is possible, or stay on a highmem-enabled LTS kernel for as long
> as necessary.

I am part of a team responsible for products based on various 32-bit SoCs,
so I'm alarmed.
These products, which include ARMv7 and PPC32 architectures with up to 2 GiB of RAM,
are communication systems with five-figure deployments worldwide.

Removing high memory will have an impact on these systems.
The oldest kernel version they run is 4.19 LTS, with upgrades to a more recent
LTS release currently in progress.
We typically upgrade the kernel every few years and will continue to support
these systems for at least the next 10 years.

Even with a new memory split, which could utilize most of the available memory,
I expect there to be issues with various applications and FPGA device drivers.

Thanks,
//richard