[PATCH 08/10] arm64: stacktrace: report recovered PCs

[Miroslav Benes]

On Thu, 10 Oct 2024, Mark Rutland wrote:

> When analysing a stacktrace it can be useful to know whether an unwound
> PC has been rewritten by fgraph or kretprobes, as in some situations
> these may be suspect or be known to be unreliable.
> 
> This patch adds flags to track when an unwind entry has recovered the PC
> from fgraph and/or kretprobes, and updates dump_backtrace() to log when
> this is the case.
> 
> The flags recorded are:
> 
>  "F" - the PC was recovered from fgraph
>  "K" - the PC was recovered from kretprobes
> 
> These flags are recorded and logged in addition to the original source
> of the unwound PC.
> 
> For example, with the ftrace_graph profiler enabled globally, and
> kretprobes installed on generic_handle_domain_irq() and
> do_interrupt_handler(), a backtrace triggered by magic-sysrq + L
> reports:
> 
> | Call trace:
> |  show_stack+0x20/0x40 (CF)
> |  dump_stack_lvl+0x60/0x80 (F)
> |  dump_stack+0x18/0x28
> |  nmi_cpu_backtrace+0xfc/0x140
> |  nmi_trigger_cpumask_backtrace+0x1c8/0x200
> |  arch_trigger_cpumask_backtrace+0x20/0x40
> |  sysrq_handle_showallcpus+0x24/0x38 (F)
> |  __handle_sysrq+0xa8/0x1b0 (F)
> |  handle_sysrq+0x38/0x50 (F)
> |  pl011_int+0x460/0x5a8 (F)
> |  __handle_irq_event_percpu+0x60/0x220 (F)
> |  handle_irq_event+0x54/0xc0 (F)
> |  handle_fasteoi_irq+0xa8/0x1d0 (F)
> |  generic_handle_domain_irq+0x34/0x58 (F)
> |  gic_handle_irq+0x54/0x140 (FK)
> |  call_on_irq_stack+0x24/0x58 (F)
> |  do_interrupt_handler+0x88/0xa0
> |  el1_interrupt+0x34/0x68 (FK)
> |  el1h_64_irq_handler+0x18/0x28
> |  el1h_64_irq+0x64/0x68
> |  default_idle_call+0x34/0x180
> |  do_idle+0x204/0x268
> |  cpu_startup_entry+0x40/0x50 (F)
> |  rest_init+0xe4/0xf0
> |  start_kernel+0x744/0x750
> |  __primary_switched+0x80/0x90
> 
> Note that as these flags are reported next to the recovered PC value,
> they appear on the callers of instrumented functions, e.g.
> gic_handle_irq has a "K" marker because generic_handle_domain_irq was
> instrumented with kretprobes and had its return addredd (gic_handle_irq)

address

Also, you might want to add () to all the functions here to keep it 
consistent with the rest of the changelog even though the call trace does 
not have them obviously.

Miroslav