Messages in this thread Patch in this message | | | From | Ding Hui <> | Subject | [RFC PATCH] arch/arm64: put crash_save_cpu() at last before die | Date | Thu, 1 Dec 2022 16:33:13 +0800 |
| |
When we debug a vmcore by crash utility, sometimes we got backtraces on non-panic core like this:
crash> bt -c 1 PID: 0 TASK: ffff80014107a000 CPU: 1 COMMAND: "swapper/1" #0 [1ffff0002f73c7dc] crash_save_cpu at ffff20002031cb68
The crash utility do backtrace by search LR from stack, which pushed by callee of crash_save_cpu().
So the LR is easier to be destroyed by subsequent invoking other functions, and lead to crash failed to backtrace on non-panic core
I tried to put crash_save_cpu() after sdei_mask_local_cpu(), and it turns out bt is working to me.
But I'm not sure the order of crash_save_cpu() is whether strictly required, so I send this RFC patch to get some suggestion.
Signed-off-by: Ding Hui <dinghui@sangfor.com.cn> --- arch/arm64/kernel/smp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index ffc5d76cf695..5f1defe76f3d 100644 --- a/arch/arm64/kernel/smp.c +++ b/arch/arm64/kernel/smp.c @@ -842,13 +842,13 @@ static atomic_t waiting_for_crash_ipi = ATOMIC_INIT(0); static void ipi_cpu_crash_stop(unsigned int cpu, struct pt_regs *regs) { #ifdef CONFIG_KEXEC_CORE - crash_save_cpu(regs, cpu); - atomic_dec(&waiting_for_crash_ipi); local_irq_disable(); sdei_mask_local_cpu(); + crash_save_cpu(regs, cpu); + if (IS_ENABLED(CONFIG_HOTPLUG_CPU)) __cpu_try_die(cpu); -- 2.17.1
| |