Thread (32 messages) 32 messages, 5 authors, 2023-08-22

Re: [PATCH v9 5/7] arm64: ipi_debug: Add support for backtrace using the debug IPI

From: Mark Rutland <mark.rutland@arm.com>
Date: 2023-08-22 06:36:00
Also in: linux-perf-users, lkml

On Mon, Aug 21, 2023 at 05:06:50PM -0700, Doug Anderson wrote:
On Mon, Aug 7, 2023 at 3:23 AM Mark Rutland [off-list ref] wrote:
quoted
On Thu, Jun 01, 2023 at 02:31:49PM -0700, Douglas Anderson wrote:
quoted
From: Sumit Garg <redacted>
quoted
quoted
 static irqreturn_t ipi_debug_handler(int irq, void *data)
 {
-     /* nop, NMI handlers for special features can be added here. */
+     irqreturn_t ret = IRQ_NONE;
+
+     /*
+      * NOTE: Just like in arch_trigger_cpumask_backtrace(), we're calling
+      * a function with "nmi_" in the name but it works fine even if we
+      * are using a regulaor IPI.
+      */
+     if (nmi_cpu_backtrace(get_irq_regs()))
+             ret = IRQ_HANDLED;
Does this need the printk_deferred_{enter,exit}() that 32-bit arm has?
I don't _think_ so, but I also don't _think_ it's needed for arm32.
;-) Let me explain my logic and you can tell me if it sounds right to
you.

If we're doing the backtrace in pseudo-NMI context then we definitely
don't need it. Specifically, the printk_deferred_{enter,exit}() just
manages the per-cpu "printk_context" value. That value doesn't matter
if "in_nmi()" returns true.

If we're _not_ doing the backtrace in pseudo-NMI context then I think
we also don't need it. After all, if we're not in pseudo-NMI context
then it's perfectly fine to print, right?

While it's hard to know 100% for sure, my best guess is that in arm
this might have helped prevent stack traces from getting interspersed
among one another. I guess this is no longer needed as of commit
55d6af1d6688 ("lib/nmi_backtrace: explicitly serialize banner and
regs")? In any case, when I tested this earlier things seemed to
printout fine without it...
Thanks for that explanation; that makes sense to me! Looking around a bit I see
that x86 doesn't bother either.
That being said, it wouldn't hurt to include it here and I'll do it if you
want.
No need -- I'm happy without it.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help