arm64: Add support for on-demand backtrace of other CPUs
Subsystems (2)
PATCH 1/1 arm64: Add support for on-demand backtrace of other CPUs
From: Oleksandr Andrushchenko <[email protected]>
Hi, all!
Please ignore initial version of the patch in favor of this one:
this is the rebased and updated version of the [1] which unfortunately haven't landed into the kernel and stuck at RFC stage.
Thank you,
Oleksandr Andrushchenko
[1] https://lkml.org/lkml/2016/8/19/591
Daniel Thompson (1):
arm64: Add support for on-demand backtrace of other CPUs
arch/arm64/include/asm/hardirq.h | 2 +- arch/arm64/include/asm/irq.h | 6 ++++++ arch/arm64/kernel/smp.c | 30 +++++++++++++++++++++++++++++- lib/nmi_backtrace.c | 8 ++++++-- 4 files changed, 42 insertions(+), 4 deletions(-)
Signature · 1 line
2.7.4
PATCH 1/1 arm64: Add support for on-demand backtrace of other CPUs
From: Daniel Thompson <[email protected]>
Currently arm64 has no implementation of arch_trigger_cpumask_backtrace. The patch provides one using library code recently added by Russell King for for the majority of the implementation. Currently this is realized using regular irqs but could, in the future, be implemented using NMI-like mechanisms.
Note: There is a small (and nasty) change to the generic code to ensure
good stack traces. The generic code currently assumes that show_regs() will include a stack trace but arch/arm64 does not do this so we must add extra code here. Ideas on a better approach here would be very welcome (is there any appetite to change arm64 show_regs() or should we just tease out the dump code into a callback?).
--- arch/arm64/include/asm/hardirq.h | 2 +- arch/arm64/include/asm/irq.h | 6 ++++++ arch/arm64/kernel/smp.c | 30 +++++++++++++++++++++++++++++- lib/nmi_backtrace.c | 8 ++++++-- 4 files changed, 42 insertions(+), 4 deletions(-)
arch/arm64/include/asm/hardirq.h +1 -1
@@ -20,7 +20,7 @@#include <linux/threads.h> #include <asm/irq.h> -#define NR_IPI 6 +#define NR_IPI 7 typedef struct { unsigned int __softirq_pending;
arch/arm64/include/asm/irq.h +6 -0
@@ -56,5 +56,11 @@ static inline bool on_irq_stack(unsigned long sp, int cpu)return (low <= sp && sp <= high); } +#ifdef CONFIG_SMP +extern void arch_trigger_cpumask_backtrace (const cpumask_t *mask, +bool exclude_self); +#define arch_trigger_cpumask_backtrace arch_trigger_cpumask_backtrace +#endif +#endif /* !__ASSEMBLER__ */ #endif
arch/arm64/kernel/smp.c +29 -1
@@ -34,6 +34,7 @@#include <linux/smp.h> #include <linux/seq_file.h> #include <linux/irq.h> +#include <linux/nmi.h> #include <linux/percpu.h> #include <linux/clockchips.h> #include <linux/completion.h>
@@ -78,7 +79,8 @@ enum ipi_msg_type {IPI_CPU_STOP ,IPI_TIMER ,IPI_IRQ_WORK , - IPI_WAKEUP +IPI_WAKEUP , + IPI_CPU_BACKTRACE, };#ifdef CONFIG_ARM64_VHE
@@ -758,6 +760,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {S (IPI_TIMER ,"Timer broadcast interrupts" ),S (IPI_IRQ_WORK ,"IRQ work interrupts" ),S (IPI_WAKEUP ,"CPU wake-up interrupts" ), + S(IPI_CPU_BACKTRACE, "backtrace interrupts"), };static void smp_cross_call (const struct cpumask *target,unsigned int ipinr)
@@ -883,6 +886,14 @@ void handle_IPI(int ipinr, struct pt_regs *regs)break ;#endif +case IPI_CPU_BACKTRACE : +printk_nmi_enter (); +irq_enter (); +nmi_cpu_backtrace (regs); +irq_exit (); +printk_nmi_exit (); +break ; +default :pr_crit ("CPU%u: Unknown IPI message 0x%x\n" , cpu, ipinr);break ;
@@ -956,3 +967,20 @@ bool cpus_are_stuck_in_kernel(void)return !!cpus_stuck_in_kernel || smp_spin_tables; } + +static void raise_nmi (cpumask_t *mask) +{ +/* +* Generate the backtrace directly if we are running in a +* calling context that is not preemptible by the backtrace IPI. +*/ +if (cpumask_test_cpu (smp_processor_id (), mask) &&irqs_disabled ()) +nmi_cpu_backtrace (NULL ); + +smp_cross_call (mask,IPI_CPU_BACKTRACE ); +} + +void arch_trigger_cpumask_backtrace (const cpumask_t *mask,bool exclude_self) +{ +nmi_trigger_cpumask_backtrace (mask, exclude_self, raise_nmi); +}
lib/nmi_backtrace.c +6 -2
@@ -94,10 +94,14 @@ bool nmi_cpu_backtrace(struct pt_regs *regs) cpu, instruction_pointer(regs)); }else {pr_warn ("NMI backtrace for cpu %d\n" , cpu); -if (regs) +if (regs) {show_regs (regs); -else +#ifdef CONFIG_ARM64 +show_stack (NULL ,NULL ); +#endif + }else {dump_stack (); + } }cpumask_clear_cpu (cpu,to_cpumask (backtrace_mask));return true;
Signature · 1 line
2.7.4
Catalin Marinas
maintainerPATCH 1/1 arm64: Add support for on-demand backtrace of other CPUs
Quoted 8 lines · Oleksandr Andrushchenko
From: Daniel Thompson <[email protected]>
Currently arm64 has no implementation of
arch_trigger_cpumask_backtrace. The patch provides one using library code recently added by Russell King for for the majority of the implementation. Currently this is realized using regular irqs but could, in the future, be implemented using NMI-like mechanisms.
Quoted 7 lines
Note: There is a small (and nasty) change to the generic code to ensure
good stack traces. The generic code currently assumes thatshow_regs()will include a stack trace butarch/arm64does not do this so we must add extra code here. Ideas on a better approach here would be very welcome (is there any appetite to change arm64show_regs()or should we just tease out the dump code into a callback?).
Please see this discussion here:
http://lkml.kernel.org/r/20170323150357.GH9287 at leverpostej
I'm not a ware of a follow up but if we change the arm64 show_regs() to dump the stack, we no longer need the generic code hunk in your patch.
Signature · 1 line
Catalin
PATCH 1/1 arm64: Add support for on-demand backtrace of other CPUs
Quoted 17 lines · Catalin Marinas
Quoted 8 lines · Oleksandr Andrushchenko
From: Daniel Thompson <[email protected]>
Currently arm64 has no implementation of
arch_trigger_cpumask_backtrace. The patch provides one using library code recently added by Russell King for for the majority of the implementation. Currently this is realized using regular irqs but could, in the future, be implemented using NMI-like mechanisms.Quoted 7 lines
Note: There is a small (and nasty) change to the generic code to ensure
good stack traces. The generic code currently assumes thatshow_regs()will include a stack trace butarch/arm64does not do this so we must add extra code here. Ideas on a better approach here would be very welcome (is there any appetite to change arm64show_regs()or should we just tease out the dump code into a callback
Quoted 6 lines
Please see this discussion here:
http://lkml.kernel.org/r/20170323150357.GH9287 at leverpostej
I'm not a ware of a follow up but if we change the arm64
show_regs()to dump the stack, we no longer need the generic code hunk in your patch.
Great. That hack did always irk me!
I'll tidy it up the next time I push out the PMR interrupt masking patch set.
Is there any interest in taking the patch before that. I don't mind separating it out... I'm just not sure how useful it is.
PATCH 1/1 arm64: Add support for on-demand backtrace of other CPUs
Quoted 27 lines · Daniel Thompson
Quoted 19 lines · Catalin Marinas
Quoted 10 lines · Oleksandr Andrushchenko
From: Daniel Thompson <[email protected]>
Currently arm64 has no implementation of
arch_trigger_cpumask_backtrace.
The patch provides one using library code recently added by Russell King
for for the majority of the implementation. Currently this is realized using regular irqs but could, in the future, be implemented using NMI-like mechanisms.Quoted 7 lines
Note: There is a small (and nasty) change to the generic code to ensure
good stack traces. The generic code currently assumes thatshow_regs()will include a stack trace butarch/arm64does not do this so we must add extra code here. Ideas on a better approach here would be very welcome (is there any appetite to change arm64show_regs()or should we just tease out the dump code into a callbackQuoted 6 lines
Please see this discussion here:
http://lkml.kernel.org/r/20170323150357.GH9287 at leverpostej
I'm not a ware of a follow up but if we change the arm64
show_regs()to dump the stack, we no longer need the generic code hunk in your patch.
Quoted 8 lines
Great. That hack did always irk me!
I'll tidy it up the next time I push out the PMR interrupt masking patch set.
Is there any interest in taking the patch before that. I don't mind separating it out... I'm just not sure how useful it is.
Yes, please, could you make it as a separate patch, so it gets in the tree faster?
As to if it is useful... It is. I am working on Xen hypervisor [1] and sometimes it is
sooo useful to see what all the cores do.
Thank you in advance,
Oleksandr