linux-kernel - Re: [PATCH 2/4] x86/mm: harmonize return value of phys_pte

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

Message-ID: <84b2e7a3-7115-45fe-89ff-db8ee46729f2@intel.com>
Date: Fri, 5 Dec 2025 11:29:05 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Brendan Jackman <jackmanb@...gle.com>, Borislav Petkov <bp@...en8.de>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] x86/mm: harmonize return value of phys_pte_init()

On 11/28/25 06:03, Brendan Jackman wrote:
> Before the patchset, the return value of kernel_physical_mapping_init()
> means something like:
> 
> 1. The last physical address that was mapped.
> 
> 2. ... This includes addresses that were already mapped before the call
> 
> 3. ... UNLESS that pre-existing mapping was 4K.

Yeah, the 4k thing certainly sounds like a bug. The *only* thing that
this influences is the add_pfn_range_mapped() call and it doesn't care
about 4k.

> I think the right way to do this is to drop this patch (2/4) and
> evaluate the remainder against the claim that init_memory_mapping()
> doesn't care about the return value at all. So that would have to mean:
> 
> a. It only calls kernel_physical_mapping_init() for physical ranges that
>    exist.
> 
> b. It always uses a page_size_mask that matches the alignment of the
>    ranges it's passing.
> 
> c. It doesn't operate on ranges that already have mappings.

Yeah, that makes sense to go forward with. Instead of having the code
try to cope with all that stuff that we don't think is happening
_anyway_, let's just warn on those conditions and effectively not handle
them.