Re: [PATCH 2/4] x86/mm: harmonize return value of phys_pte_init()

[Dave Hansen <dave.hansen@intel.com>]

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.