Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 77d09ad3 authored by Jiping Ma's avatar Jiping Ma Committed by Sasha Levin
Browse files

arm64: perf: Report the PC value in REGS_ABI_32 mode 



commit 8dfe804a4031ca6ba3a3efb2048534249b64f3a5 upstream.

A 32-bit perf querying the registers of a compat task using REGS_ABI_32
will receive zeroes from w15, when it expects to find the PC.

Return the PC value for register dwarf register 15 when returning register
values for a compat task to perf.

Cc: <stable@vger.kernel.org>
Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
Signed-off-by: default avatarJiping Ma <jiping.ma2@windriver.com>
Link: https://lore.kernel.org/r/1589165527-188401-1-git-send-email-jiping.ma2@windriver.com


[will: Shuffled code and added a comment]
Signed-off-by: default avatarWill Deacon <will@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent 6306edad

arch/arm64/kernel/perf_regs.c

+22 −3
Original line number Diff line number Diff line
@@ -15,15 +15,34 @@ u64 perf_reg_value(struct pt_regs *regs, int idx) 
		return 0;



	/*

	 * Compat (i.e. 32 bit) mode:

	 * - PC has been set in the pt_regs struct in kernel_entry,

	 * - Handle SP and LR here.

	 * Our handling of compat tasks (PERF_SAMPLE_REGS_ABI_32) is weird, but

	 * we're stuck with it for ABI compatability reasons.

	 *

	 * For a 32-bit consumer inspecting a 32-bit task, then it will look at

	 * the first 16 registers (see arch/arm/include/uapi/asm/perf_regs.h).

	 * These correspond directly to a prefix of the registers saved in our

	 * 'struct pt_regs', with the exception of the PC, so we copy that down

	 * (x15 corresponds to SP_hyp in the architecture).

	 *

	 * So far, so good.

	 *

	 * The oddity arises when a 64-bit consumer looks at a 32-bit task and

	 * asks for registers beyond PERF_REG_ARM_MAX. In this case, we return

	 * SP_usr, LR_usr and PC in the positions where the AArch64 SP, LR and

	 * PC registers would normally live. The initial idea was to allow a

	 * 64-bit unwinder to unwind a 32-bit task and, although it's not clear

	 * how well that works in practice, somebody might be relying on it.

	 *

	 * At the time we make a sample, we don't know whether the consumer is

	 * 32-bit or 64-bit, so we have to cater for both possibilities.

	 */

	if (compat_user_mode(regs)) {

		if ((u32)idx == PERF_REG_ARM64_SP)

			return regs->compat_sp;

		if ((u32)idx == PERF_REG_ARM64_LR)

			return regs->compat_lr;

		if (idx == 15)

			return regs->pc;

	}



	if ((u32)idx == PERF_REG_ARM64_SP)