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

[Brendan Jackman <jackmanb@google.com>]

On Fri Dec 5, 2025 at 7:29 PM UTC, Dave Hansen wrote:
> 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.

I assume those conditions can arise in other cases than
init_memory_mapping(). It's just that those cases already ignore the
return value so it doesn't matter anyway.

Anyway yeah will go ahead with this approach, minus the warnings.
Probably after LPC as I am still not finished with my page_alloc
stuff (yikes!).