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