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

[Ard Biesheuvel]

On Mon, 2 Feb 2026, at 08:18, Arnd Bergmann wrote:
> On Wed, Sep 17, 2025, at 21:02, Yang Shi wrote:
>
>> +	.pushsection ".idmap.text", "a"
>> +SYM_TYPED_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
>> +
>> +	mrs     swapper_ttb, ttbr1_el1
>> +	adr_l   flag_ptr, idmap_kpti_bbml2_flag
>> +	__idmap_cpu_set_reserved_ttbr1 x16, x17
>
> I'm getting build failures here, using CONFIG_CFI using clang-21:
>
> ld.lld-21: error: undefined symbol: __kcfi_typeid_wait_linear_map_split_to_ptes
>>>> referenced by arch/arm64/mm/proc.o:(.idmap.text+0x298) in archive vmlinux.a
>
> I can get it to build by using plain SYM_FUNC_START() instead of
> SYM_TYPED_FUNC_START(), but I have no idea if that makes any sense:
>
> --- 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?