为什么“echo l > /proc/sysrq-trigger”调用跟踪输出总是相似的？

Question

根据官方 kernel.org 文档 echo l > /proc/sysrq-trigger应该给我所有 CPU 的当前调用跟踪。但是当我这样做几次并查看dmesg之后，调用跟踪看起来完全相似。这是为什么？

Answer 1

相同的回溯解释

在您的情况下，您的 CPU #0 回溯显示它正在执行您的 sysrq 命令（根据write_sysrq_trigger()功能判断）：

delay_tsc+0x1f/0x70
arch_trigger_all_cpu_backtrace+0x10a/0x140
__handle_sysrq+0xfc/0x160
write_sysrq_trigger+0x2b/0x30
proc_reg_write+0x39/0x70
vfs_write+0xb2/0x1f0
SyS_write+0x42/0xa0
system_call_fast_compare_end+0x10/0x15

并且 CPU #1 回溯显示它处于空闲状态（根据cpuidle_enter_state()功能判断）：

cpuidle_enter_state+0x40/0xc0
cpu_startup_entry+0x2f8/0x400
start_secondary+0x20f/0x2d0

尝试非常密集地加载您的系统，然后执行您的 sysrq 命令以获取新的回溯。您将看到一个 CPU 正在执行您的 sysrq 命令，而第二个 CPU 不再处于空闲状态，而是在执行一些实际工作。

用户空间回溯

至于内核回溯上的用户空间函数：尽管系统调用正在代表用户空间进程（在内核空间中）执行（参见Comm: bashCPU0 的回溯），但无法使用标准内核回溯打印用户空间进程回溯机制（在dump_stack()函数中实现）。问题是内核堆栈不包含任何用户空间进程调用（这就是为什么您只能在回溯中看到内核函数的原因）。

可以在相应进程的用户空间堆栈中找到用户空间进程调用。为此，我建议您使用OProfile分析器。当然，它只会给你一个二进制堆栈。为了获得实际的函数名称，您需要向 gdb 提供符号信息。

细节：

[1]内核栈和用户空间栈

[2]如何在系统调用中转储内核堆栈

[3]如何在linux kernelspace中打印用户空间堆栈跟踪