Re: [PATCH v9 7/7] arm64: kgdb: Roundup cpus using the debug IPI

On Mon, Aug 07, 2023 at 05:04:14PM +0100, Mark Rutland wrote:

On Mon, Aug 07, 2023 at 04:24:44PM +0100, Daniel Thompson wrote:

quoted

On Mon, Aug 07, 2023 at 11:28:52AM +0100, Mark Rutland wrote:

quoted

On Thu, Jun 01, 2023 at 02:31:51PM -0700, Douglas Anderson wrote:

quoted

From: Sumit Garg <redacted>

Let's use the debug IPI for rounding up CPUs in kgdb. When the debug
IPI is backed by an NMI (or pseudo NMI) then this will let us debug
even hard locked CPUs. When the debug IPI isn't backed by an NMI then
this won't really have any huge benefit but it will still work.

Signed-off-by: Sumit Garg <redacted>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v9:
- Remove fallback for when debug IPI isn't available.
- Renamed "NMI IPI" to "debug IPI" since it might not be backed by NMI.

 arch/arm64/kernel/ipi_debug.c |  5 +++++
 arch/arm64/kernel/kgdb.c      | 14 ++++++++++++++
 2 files changed, 19 insertions(+)

This looks fine to me, but I'd feel a bit happier if we had separate SGIs for
the backtrace and the KGDB callback as they're logically unrelated.

I've no objections to seperate SGIs (if one can be found) but I'm curious
what benefit emerges from giving them seperate IPIs.

Mostly an "I'd feel happier"; they're logically unrelated and having them
separate avoids the risk of them unintentionally getting in the way of the
other.

quoted

Both interfaces are already designed to share and NMI-like IPI nicely
(and IIUC they must share one on x86), neither is performance
critical[1] and the content of /proc/interrupts for the IPI is seldom
going to be of much interest.

Sure; I understand that. The flip side of "neither is performance critical" is
that they're seldom tested in terms of interaction with one another, and hence
for robustness I'd prefer they're separate.

We can't really stop them interacting when kdb is enabled: both activate
special logic to intercept console messages and this is much more
complex than the "is this my IPI?" tests.

I agree it's not strictly necessary, but given we can easily free up an SGI
slot, I think it'd be worthwhile. We can always decide to fold them together in
future if we have to.

Agreed.

It should be very little bother to "reclaim" an IPI from the diagnostics
machinery if that is ever needed. So seperate IPIs is no problem from my
point of view.


Daniel.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel