[PATCH] arm64/alternatives: don't patch up internal branches

Alexandru Elisei alexandru.elisei at arm.com
Thu Jul 9 09:14:15 EDT 2020


Hi Ard,

On 7/9/20 1:59 PM, Ard Biesheuvel wrote:
> Commit f7b93d429 ("arm64/alternatives: use subsections for replacement
> sequences") moved the alternatives replacement sequences into subsections,
> in order to keep the as close as possible to the code that they replace.
>
> Unfortunately, this broke the logic in branch_insn_requires_update,
> which assumed that any branch into kernel executable code was a branch
> that required updating, which is no longer the case now that the code
> sequences that are patched in are in the same section as the patch site
> itself.
>
> So the only way to discriminate branches that require updating and ones
> that don't is to check whether the branch targets the replacement sequence
> itself, and so we can drop the call to kernel_text_address() entirely.
>
> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> ---
>  arch/arm64/kernel/alternative.c | 12 +-----------
>  1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
> index d1757ef1b1e7..5711adda14bb 100644
> --- a/arch/arm64/kernel/alternative.c
> +++ b/arch/arm64/kernel/alternative.c
> @@ -45,18 +45,8 @@ static bool branch_insn_requires_update(struct alt_instr *alt, unsigned long pc)
>  {
>  	unsigned long replptr;
>  
> -	if (kernel_text_address(pc))
> -		return true;
> -
>  	replptr = (unsigned long)ALT_REPL_PTR(alt);
> -	if (pc >= replptr && pc <= (replptr + alt->alt_len))
> -		return false;
> -
> -	/*
> -	 * Branching into *another* alternate sequence is doomed, and
> -	 * we're not even trying to fix it up.
> -	 */
> -	BUG();
> +	return !(pc >= replptr && pc <= (replptr + alt->alt_len));
>  }
>  
>  #define align_down(x, a)	((unsigned long)(x) & ~(((unsigned long)(a)) - 1))

Ran some perf tests on the model and rockpro64 using the PMU interrupt as an NMI,
everything works as expected:

Tested-by: Alexandru Elisei <alexandru.elisei at arm.com>

Thanks,
Alex



More information about the linux-arm-kernel mailing list