Messages in this thread | | | Date | Tue, 22 Aug 2023 07:35:41 +0100 | From | Mark Rutland <> | Subject | Re: [PATCH v9 5/7] arm64: ipi_debug: Add support for backtrace using the debug IPI |
| |
On Mon, Aug 21, 2023 at 05:06:50PM -0700, Doug Anderson wrote: > On Mon, Aug 7, 2023 at 3:23 AM Mark Rutland <mark.rutland@arm.com> wrote: > > On Thu, Jun 01, 2023 at 02:31:49PM -0700, Douglas Anderson wrote: > > > From: Sumit Garg <sumit.garg@linaro.org>
> > > 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.
| |