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: <aMDYdp3H-yOHU1Pm@casper.infradead.org>
Date: Wed, 10 Sep 2025 02:46:30 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Arnd Bergmann <arnd@...db.de>
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>,
	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 Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
> 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 don't mind that the feature remains ... unless it causes us trouble.
Which it currently does.  Perhaps we could start by removing HIGHPTE?
There was a certain amount of complexity introduced into the page fault
path when support for that was introduced.  x86 removed support for it,
so it's just ARM left before we can remove the complexity again.

Most of the other pain points are around storing metadata (directories,
superblocks, etc) in page cache highmem.  I think we can get rid of that
now too.

I don't see any particular need to gt rid of file data stored in highmem,
nor anonymous memory stored in highmem.  And if we're only talking
about hundreds of megabytes of memory, I think anon+ file pagecache is
probably most of the memory in the system already unless you have some
very weird workloads.

Where we may want to be a bit careful is some people have Plans to
reuse the kmap infrastructure to support things like unmapping the
pagecacheto protect against spectre-eqsue attacks.  I know Intel was
working on this when 3dxp was going to be a Thing, but it's recently
been brought back:

https://lore.kernel.org/linux-mm/20250812173109.295750-1-jackmanb@google.com/