While it is tempting to use printk or pr_info when coding in order to trace function in the Linux kernel calls, it turns out that there os a; ready a utility to simplify that. Here are the steps I used to enable ftrace for mcpt-pcc and figuring out where a function call stack ended (in the middle of a debugging session where I had broken it)
mount -t tracefs nodev /sys/kernel/tracing echo pcc_mbox* > /sys/kernel/tracing/set_ftrace_filter echo mctp_pcc* >> /sys/kernel/tracing/set_ftrace_filter echo function > /sys/kernel/tracing/current_tracer |
This is what I saw in the output
cat /sys/kernel/tracing/trace # tracer: function # # entries-in-buffer/entries-written: 6/6 #P:192 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | mctp-3982 [007] ..... 895.668105: mctp_pcc_ndo_open <-__dev_open mctp-3982 [007] ..... 895.668106: pcc_mbox_request_channel <-mctp_pcc_ndo_open mctp-3982 [007] ..... 895.668139: pcc_mbox_request_channel <-mctp_pcc_ndo_open mctp-client-3984 [010] b..1. 895.671158: mctp_pcc_tx <-dev_hard_start_xmit mctp-client-3984 [010] D..2. 895.671160: mctp_pcc_tx_prepare <-msg_submit mctp-client-3984 [010] D..2. 895.671160: pcc_mbox_write_to_buffer <-mctp_pcc_tx_prepare |