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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZORXPXbi3f8tUY-N@FVFF77S0Q05N>
Date:   Tue, 22 Aug 2023 07:35:41 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Sumit Garg <sumit.garg@...aro.org>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Marc Zyngier <maz@...nel.org>,
        linux-perf-users@...r.kernel.org, ito-yuichi@...itsu.com,
        Chen-Yu Tsai <wens@...e.org>, Ard Biesheuvel <ardb@...nel.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-arm-kernel@...ts.infradead.org,
        kgdb-bugreport@...ts.sourceforge.net,
        Masayoshi Mizuma <msys.mizuma@...il.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Lecopzer Chen <lecopzer.chen@...iatek.com>,
        linux-kernel@...r.kernel.org
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@....com> wrote:
> > On Thu, Jun 01, 2023 at 02:31:49PM -0700, Douglas Anderson wrote:
> > > From: Sumit Garg <sumit.garg@...aro.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.