riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled
authorChen Huang <chenhuang5@huawei.com>
Thu, 29 Apr 2021 07:03:48 +0000 (07:03 +0000)
committerPalmer Dabbelt <palmerdabbelt@google.com>
Sun, 23 May 2021 01:59:20 +0000 (18:59 -0700)
commiteac2f3059e02382d91f8c887462083841d6ea2a3
treeb2a5e92f2ee0853bd578038c348efaea5a825cb6
parent6efb943b8616ec53a5e444193dccf1af9ad627b5
riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled

As [1] and [2] said, the arch_stack_walk should not to trace itself, or it will
leave the trace unexpectedly when called. The example is when we do "cat
/sys/kernel/debug/page_owner", all pages' stack is the same.

arch_stack_walk+0x18/0x20
stack_trace_save+0x40/0x60
register_dummy_stack+0x24/0x5e
init_page_owner+0x2e

So we use __builtin_frame_address(1) as the first frame to be walked. And mark
the arch_stack_walk() noinline.

We found that pr_cont will affact pages' stack whose task state is RUNNING when
testing "echo t > /proc/sysrq-trigger". So move the place of pr_cont and mark
the function dump_backtrace() noinline.

Also we move the case when task == NULL into else branch, and test for it in
"echo c > /proc/sysrq-trigger".

[1] https://lore.kernel.org/lkml/20210319184106.5688-1-mark.rutland@arm.com/
[2] https://lore.kernel.org/lkml/20210317142050.57712-1-chenjun102@huawei.com/

Signed-off-by: Chen Huang <chenhuang5@huawei.com>
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
arch/riscv/kernel/stacktrace.c