linux-kernel - Re: [PATCH] RFC: ARM: drop support for HIGHPTE

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: <7dfbb373-fb44-48d1-9880-747faa47e079@app.fastmail.com>
Date: Wed, 10 Sep 2025 14:14:38 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Walleij" <linus.walleij@...aro.org>,
 "Russell King" <linux@...linux.org.uk>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 "Russell King" <rmk+kernel@...linux.org.uk>,
 "Matthew Wilcox" <willy@...radead.org>
Subject: Re: [PATCH] RFC: ARM: drop support for HIGHPTE

On Wed, Sep 10, 2025, at 11:47, Linus Walleij wrote:
> Matthew Wilcox suggests HIGHPTE is a burden for the
> kernel MM, and only one ARM system (vt8500) is currently
> using it.

I think the vt8500_v6_v7_defconfig entry is a historic leftover,
instead it is currently enabled by default on all configurations
that enable highmem.

> This deletes the use of HIGHPTE in ARM32 clearing the way
> to remove the feature altogether.
>
> It was introduced in commit 65cec8e3db60 "ARM: implement highpte"
> in 2009, so this RFC is intended as a discussion item to
> check if it is still a desired feature 16 years later
> or if we can get rid of it.

We discussed it last year in the context of the PREEMPT_RT patches, see
https://lore.kernel.org/linux-arm-kernel/20241210160556.2341497-4-arnd@kernel.org/
and Russell's reply to that.

I still think that dropping it is the sensible tradeoff here in
the end, as it should allow further simplifications in the
pgalloc code. Your version of this patch doesn't (like my
identical patch from December) actually do any of that though.

> -	pte = __pte_alloc_one(mm, GFP_PGTABLE_USER | PGTABLE_HIGHMEM);
> +	pte = __pte_alloc_one(mm, GFP_PGTABLE_USER);
>  	if (!pte)
>  		return NULL;
>  	if (!PageHighMem(pte))

At the minimum, PageHighMem(pte) is now know to be false, so
this could be further simplified. I tried figuring out if we can
remove __HAVE_ARCH_PTE_ALLOC_ONE altogether, but I'm not sure
where else the clean_pte_table() call on arm would happen.

   Arnd