Re: [PATCH v4 2/8] arm64/runtime-const: Use aarch64_insn_patch_text_nosync() for patching

[Catalin Marinas <catalin.marinas@arm.com>]

On Thu, Apr 30, 2026 at 09:47:24AM +0000, K Prateek Nayak wrote:
> The current scheme to directly patch the kernel text for runtime
> constants runs into the following issue with futex adapted to using
> runtime constants on arm64:
> 
>   Unable to handle kernel write to read-only memory at virtual address ...
> 
> The pc points to the *p assignment in the following call chain:
> 
>   futex_init()
>     runtime_const_init(shift, __futex_shift)
>       __runtime_fixup_shift()
>         *p = cpu_to_le32(insn);
> 
> which suggests that core_initcall() is too late to patch the kernel text
> directly unlike the "d_hash_shift" which is initialized during
> vfs_caches_init_early() before the protections are in place.
> 
> Use aarch64_insn_patch_text_nosync() to patch the runtime constants
> instead of doing it directly to allow runtime_const_init() slightly
> later into the boot.
> 
> Since aarch64_insn_patch_text_nosync() calls caches_clean_inval_pou()
> internally, __runtime_fixup_caches() ends up being redundant.
> runtime_const_init() are rare and the overheads of multiple calls to
> caches_clean_inval_pou() instead of batching them together should be
> negligible in practice.
> 
> The cpu_to_le32() conversion of instruction isn't necessary since it is
> handled later in the aarch64_insn_patch_text_nosync() call-chain:
> 
>   aarch64_insn_patch_text_nosync(addr, insn)
>     aarch64_insn_write(addr, insn)
>       __aarch64_insn_write(addr, cpu_to_le32(insn))
> 
> Sashiko noted that aarch64_insn_patch_text_nosync() does not expect a
> lm_alias() address and Catalin suggested it is safe to drop the
> lm_alias() for runtime patching since the kernel text is readable. The
> address passed to fixup function is interpreted as a __le32 and
> dereferenced as is to read the opcode at the patch site.
> 
> No functional changes are intended.
> 
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>