linux-kernel - Re: [PATCH Resend] mm: Refine __{pgd,p4d,pud,pmd,pte}_alloc_one

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: <f0efca40-aa3b-41ba-a8e4-c9595c19778e@app.fastmail.com>
Date: Fri, 07 Nov 2025 13:50:06 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Lance Yang" <ioworker0@...il.com>, "Huacai Chen" <chenhuacai@...ngson.cn>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
 "Huacai Chen" <chenhuacai@...nel.org>, "Jan Kara" <jack@...e.cz>,
 "Kevin Brodsky" <kevin.brodsky@....com>,
 Linux-Arch <linux-arch@...r.kernel.org>, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, david@...nel.org,
 "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>, vishal.moola@...il.com,
 "Lance Yang" <lance.yang@...ux.dev>
Subject: Re: [PATCH Resend] mm: Refine __{pgd,p4d,pud,pmd,pte}_alloc_one_*() about
 HIGHMEM

On Fri, Nov 7, 2025, at 12:44, Lance Yang wrote:
> From: Lance Yang <lance.yang@...ux.dev>
> On Fri,  7 Nov 2025 17:59:22 +0800, Huacai Chen wrote:
>> 
>>   */
>>  static inline pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm)
>>  {
>> -	struct ptdesc *ptdesc = pagetable_alloc_noprof(GFP_PGTABLE_KERNEL &
>> -			~__GFP_HIGHMEM, 0);
>> +	struct ptdesc *ptdesc = pagetable_alloc_noprof(GFP_PGTABLE_KERNEL, 0);
>
> I looked into the history and it seems you are right. This defensive pattern
> was likely introduced by Vishal Moola in commit c787ae5[1].

Right, so not even so long ago, so we need to make sure we agree
on a direction and don't send opposite patches in the name of
cleanups.

> After this cleanup, would it make sense to add a BUILD_BUG_ON() somewhere
> to check that __GFP_HIGHMEM is not present in GFP_PGTABLE_KERNEL and
> GFP_PGTABLE_USER? This would prevent any future regression ;)
>
> Just a thought ...

I think we can go either way here, but I'd tend towards not
adding more checks but instead removing any mention of __GFP_HIGHMEM
that we can show is either pointless or can be avoided, with
the goal of having only a small number of actual highmem
allocations remaining in places we do care about (normal
page cache, zram, possibly huge pages).

      Arnd