【Ftrace专栏】Linux内核社区补丁：关于使用stacktrace输出抢占计数问题

Linux内核社区补丁：关于使用stacktrace输出抢占计数问题

trace_stack 社区补丁

• 1、当Ftrace使用trace_stack时，preempt_count抢占计数显示为当前计数。
• 2、但如果显示为抓取时刻的抢占计数更为贴切实际查看需求。
• 3、如补丁解释：
  • 即在回调traec函数前后会有抢占计数的操作，故函数内核显示的为进入trace后人为新增加后的抢占计数值。
  • 故应该使用tracing_gen_ctx_dec()再人为的减去相应操作，
  • 此时preempt_count值更为贴切实际需求。

The preemption count of the stacktrace filter command to trace ksys_read
is consistently incorrect:

$ echo ksys_read:stacktrace > set_ftrace_filter

   <...>-453     [004] ...1.    38.308956: <stack trace>
=> ksys_read
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe

The root cause is that the trace framework disables preemption when
invoking the filter command callback in function_trace_probe_call:

   preempt_disable_notrace();
   probe_ops->func(ip, parent_ip, probe_opsbe->tr, probe_ops, probe->data);
   preempt_enable_notrace();

Use tracing_gen_ctx_dec() to account for the preempt_disable_notrace(),
which will output the correct preemption count:

$ echo ksys_read:stacktrace > set_ftrace_filter

   <...>-410     [006] .....    31.420396: <stack trace>
=> ksys_read
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe