Re: [PATCH v8 4/5] arm64: mm: split linear mapping if BBML2 unsupported on secondary CPUs

["Arnd Bergmann" <arnd@arndb.de>]

On Mon, Feb 2, 2026, at 08:43, Ard Biesheuvel wrote:
> On Mon, 2 Feb 2026, at 08:18, Arnd Bergmann wrote:
>> On Wed, Sep 17, 2025, at 21:02, Yang Shi wrote:
>> --- a/arch/arm64/mm/proc.S
>> +++ b/arch/arm64/mm/proc.S
>> @@ -439,7 +439,7 @@ SYM_FUNC_END(idmap_kpti_install_ng_mappings)
>>  #endif
>> 
>>         .pushsection ".idmap.text", "a"
>> -SYM_TYPED_FUNC_START(wait_linear_map_split_to_ptes)
>> +SYM_FUNC_START(wait_linear_map_split_to_ptes)
>>         /* Must be same registers as in idmap_kpti_install_ng_mappings */
>>         swapper_ttb     .req    x3
>>         flag_ptr        .req    x4
>>
>
> This is not the right fix: the indirect call from 
> linear_map_split_to_ptes() will be instrumented, and so it requires the 
> CFI annotation to precede the function entry point, which is what 
> SYM_TYPED_FUNC_START() is supposed to emit.
>
> The typeid symbol is injected by the compiler into every object file 
> that takes the address of the function in question, and so the fact 
> that it is missing seems to suggest that linear_map_split_to_ptes() has 
> been optimized away entirely. Could you double check 
> arch/arm64/mm/mmu.o if that is the case?

Ah, thanks for the explanation. This has indeed been optimized out
by a patch in my randconfig tree that makes CONFIG_SMP optional
for arm64. Without SMP, the calling code path is never used because
smp_processor_id() is fixed to 0.

I'll fix up that other patch then.

     Arnd