public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Tengda Wu <wutengda@huaweicloud.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	leo.yan@linux.dev, Li Huafei <lihuafei1@huawei.com>,
	Ian Rogers <irogers@google.com>,
	Kim Phillips <kim.phillips@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Bill Wendling <morbo@google.com>,
	Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Zecheng Li <zli94@ncsu.edu>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	llvm@lists.linux.dev
Subject: Re: [PATCH v2 16/16] perf annotate-arm64: Support 'mrs' instruction to track 'current' pointer
Date: Thu, 9 Apr 2026 23:52:35 -0700	[thread overview]
Message-ID: <adieMzY6o4yXGdFS@google.com> (raw)
In-Reply-To: <20260403094800.1418825-17-wutengda@huaweicloud.com>

On Fri, Apr 03, 2026 at 09:48:00AM +0000, Tengda Wu wrote:
> Extend update_insn_state() for arm64 to handle the 'mrs' instruction,
> enabling the tracking of the 'current' task pointer in the kernel.
> 
> On arm64, the kernel uses the 'sp_el0' system register to store the
> address of the currently executing 'struct task_struct'. This is
> typically accessed via the 'get_current()' inline function, resulting
> in the instruction 'mrs xN, sp_el0'.
> 
> To resolve the data type of the target register, first verify the
> access is to 'sp_el0' within a kernel DSO. Then, locate the
> 'get_current()' inline function's DWARF Die at the current PC and
> extract its return type (which is 'struct task_struct *').
> 
> Introduce a global 'task_struct_off' cache to store the DWARF offset
> of this type. This is particularly important because the compiler-generated
> stack canary check code (which loads from 'current') often exists in
> code sections or leaf functions where the local Compilation Unit (CU)
> lacks a full 'struct task_struct' definition. Caching the offset allows
> 'perf annotate' to consistently resolve task-related fields across the
> entire kernel binary.
> 
> A real-world example is shown below:
> 
>   ffff8000800deee8 <kthread_blkcg>:
>   ffff8000800deef0:  mrs  x0, sp_el0    // x0 = current
>   ffff8000800deef4:  ldr  w1, [x0, #44] // Access task_struct member
> 
> Before this commit, the type flow starts with no information:
> 
>   chk [c] reg0 offset=0x2c ok=0 kind=0 cfa : no type information
>   final result: no type information
> 
> After this commit, the tracker identifies the 'current' pointer
> from the system register:
> 
>   mrs [8] sp_el0 -> reg0 type='struct task_struct*'
>   chk [c] reg0 offset=0x2c ok=1 kind=1 (struct task_struct*) : Good!
>   found by insn track: 0x2c(reg0) type-offset=0x2c
>   final result: type='struct task_struct'
> 
> Signed-off-by: Li Huafei <lihuafei1@huawei.com>
> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
> ---
>  .../perf/util/annotate-arch/annotate-arm64.c  | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/tools/perf/util/annotate-arch/annotate-arm64.c b/tools/perf/util/annotate-arch/annotate-arm64.c
> index 89b6b596f984..b03b12594260 100644
> --- a/tools/perf/util/annotate-arch/annotate-arm64.c
> +++ b/tools/perf/util/annotate-arch/annotate-arm64.c
> @@ -14,6 +14,7 @@
>  #include "../debug.h"
>  #include "../map.h"
>  #include "../symbol.h"
> +#include "../dso.h"
>  
>  struct arch_arm64 {
>  	struct arch arch;
> @@ -289,6 +290,8 @@ static void adjust_reg_index_state(struct type_state *state, int reg,
>  	pr_debug_type_name(&tsr->type, tsr->kind);
>  }
>  
> +static Dwarf_Off task_struct_off;
> +
>  static void update_insn_state_arm64(struct type_state *state,
>  				    struct data_loc_info *dloc, Dwarf_Die *cu_die,
>  				    struct disasm_line *dl)
> @@ -309,6 +312,56 @@ static void update_insn_state_arm64(struct type_state *state,
>  	sreg = src->reg1;
>  	dreg = dst->reg1;
>  
> +	if (!strcmp(dl->ins.name, "mrs")) {
> +		Dwarf_Die func_die;
> +		Dwarf_Attribute attr;
> +		u64 ip, pc;
> +
> +		if (!has_reg_type(state, sreg))
> +			return;
> +
> +		/* Handle case difference: LLVM (SP_EL0) vs objdump (sp_el0) */
> +		if (!dso__kernel(map__dso(dloc->ms->map)) ||
> +		    strcasecmp(dl->ops.target.raw, "sp_el0"))
> +			return;
> +
> +		ip = dloc->ms->sym->start + dl->al.offset;
> +		pc = map__rip_2objdump(dloc->ms->map, ip);
> +
> +		if (!task_struct_off ||
> +		    !dwarf_offdie(dloc->di->dbg, task_struct_off, &type_die)) {
> +			/*
> +			 * Find the inline function 'get_current()' Dwarf_Die
> +			 * and obtain its return value data type, which should
> +			 * be 'struct task_struct *'.
> +			 */
> +			if (!die_find_inlinefunc(cu_die, pc, &func_die) ||
> +			    !dwarf_attr_integrate(&func_die, DW_AT_type, &attr) ||
> +			    !dwarf_formref_die(&attr, &type_die))
> +				return;

I think it's better to verify if it's really the function and type we
want.

Thanks,
Namhyung

> +
> +			/*
> +			 * Cache the 'struct task_struct *' die offset globally.
> +			 * This allows us to resolve stack canary accesses even
> +			 * in CUs that lack a full task_struct definition (e.g.,
> +			 * compiler-generated entry/exit code).
> +			 */
> +			task_struct_off = dwarf_dieoffset(&type_die);
> +		}
> +
> +		tsr = &state->regs[sreg];
> +		tsr->copied_from = -1;
> +		tsr->type = type_die;
> +		tsr->kind = TSR_KIND_TYPE;
> +		tsr->offset = 0;
> +		tsr->addr = 0;
> +		tsr->ok = true;
> +
> +		pr_debug_dtp("mrs [%x] sp_el0 -> reg%d", insn_offset, sreg);
> +		pr_debug_type_name(&type_die, tsr->kind);
> +		return;
> +	}
> +
>  	if (!strcmp(dl->ins.name, "adrp")) {
>  		if (!has_reg_type(state, sreg) || !dl->ops.target.addr)
>  			return;
> -- 
> 2.34.1
> 

  reply	other threads:[~2026-04-10  6:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-03  9:47 [PATCH v2 00/16] perf arm64: Support data type profiling Tengda Wu
2026-04-03  9:47 ` [PATCH v2 01/16] perf llvm: Fix arm64 adrp instruction disassembly mismatch with objdump Tengda Wu
2026-04-03  9:47 ` [PATCH v2 02/16] perf capstone: Fix arm64 jump/adrp " Tengda Wu
2026-04-07  6:43   ` Namhyung Kim
2026-04-10  9:08     ` Tengda Wu
2026-04-03  9:47 ` [PATCH v2 03/16] perf annotate-arm64: Generalize arm64_mov__parse to support standard operands Tengda Wu
2026-04-07  6:58   ` Namhyung Kim
2026-04-03  9:47 ` [PATCH v2 04/16] perf annotate-arm64: Handle load and store instructions Tengda Wu
2026-04-07  7:09   ` Namhyung Kim
2026-04-03  9:47 ` [PATCH v2 05/16] perf annotate: Introduce extract_op_location callback for arch-specific parsing Tengda Wu
2026-04-03  9:47 ` [PATCH v2 06/16] perf dwarf-regs: Adapt get_dwarf_regnum() for arm64 Tengda Wu
2026-04-03  9:47 ` [PATCH v2 07/16] perf annotate-arm64: Implement extract_op_location() callback Tengda Wu
2026-04-07  7:26   ` Namhyung Kim
2026-04-03  9:47 ` [PATCH v2 08/16] perf annotate-arm64: Enable instruction tracking support Tengda Wu
2026-04-10  6:09   ` Namhyung Kim
2026-04-03  9:47 ` [PATCH v2 09/16] perf annotate-arm64: Support load instruction tracking Tengda Wu
2026-04-10  6:23   ` Namhyung Kim
2026-04-03  9:47 ` [PATCH v2 10/16] perf annotate-arm64: Support store " Tengda Wu
2026-04-03  9:47 ` [PATCH v2 11/16] perf annotate-arm64: Support stack variable tracking Tengda Wu
2026-04-10  6:29   ` Namhyung Kim
2026-04-03  9:47 ` [PATCH v2 12/16] perf annotate-arm64: Support 'mov' instruction tracking Tengda Wu
2026-04-10  6:39   ` Namhyung Kim
2026-04-03  9:47 ` [PATCH v2 13/16] perf annotate-arm64: Support 'add' " Tengda Wu
2026-04-10  6:42   ` Namhyung Kim
2026-04-03  9:47 ` [PATCH v2 14/16] perf annotate-arm64: Support 'adrp' instruction to track global variables Tengda Wu
2026-04-03  9:47 ` [PATCH v2 15/16] perf annotate-arm64: Support per-cpu variable access tracking Tengda Wu
2026-04-03  9:48 ` [PATCH v2 16/16] perf annotate-arm64: Support 'mrs' instruction to track 'current' pointer Tengda Wu
2026-04-10  6:52   ` Namhyung Kim [this message]
2026-04-07  6:31 ` [PATCH v2 00/16] perf arm64: Support data type profiling Namhyung Kim
2026-04-08 11:35   ` Tengda Wu
2026-04-10  7:00     ` Namhyung Kim
2026-04-10  8:17       ` Tengda Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adieMzY6o4yXGdFS@google.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=kim.phillips@arm.com \
    --cc=leo.yan@linux.dev \
    --cc=lihuafei1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=morbo@google.com \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=peterz@infradead.org \
    --cc=wutengda@huaweicloud.com \
    --cc=zli94@ncsu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox