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

[Mark Rutland <mark.rutland@arm.com>]

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.