public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Misono Tomohiro <misono.tomohiro@fujitsu.com>,
	Chen-Yu Tsai <wens@csie.org>, Stephen Boyd <swboyd@chromium.org>,
	Sumit Garg <sumit.garg@linaro.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tony Luck <tony.luck@intel.com>,
	Valentin Schneider <vschneid@redhat.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI first
Date: Fri, 1 Mar 2024 11:42:11 +0000	[thread overview]
Message-ID: <20240301114211.GC5795@aspen.lan> (raw)
In-Reply-To: <CAD=FV=VYV_EMFXS0vvMZLGSRZcGwit6=DMdgSW349bVAu_7a1Q@mail.gmail.com>

On Thu, Feb 29, 2024 at 10:34:26AM -0800, Doug Anderson wrote:
> Hi,
>
> On Wed, Feb 28, 2024 at 5:11 AM Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> >
> > > I'm still hoping to get some sort of feedback here. If people think
> > > this is a terrible idea then I'll shut up now and leave well enough
> > > alone, but it would be nice to actively decide and get the patch out
> > > of limbo.
> >
> > I've read patch through a couple of times and was generally convinced by
> > the "do what x86 does" argument.
> >
> > However until now I've always held my council since I wasn't familiar
> > with these code paths and I figured it was OK for me to have no opinion
> > because the first line of the description says that kgdb/kdb is 100% not
> > involved in causing the problem ;-) .
> >
> > However today I also took a look at the HAVE_NMI architectures and there
> > is no consensus between them about how to implement this: PowerPC uses
> > NMI and most of the others use IRQ only, s390 special cases for the
> > panic code path and acts differently compared to a normal SMP shutdown.
> >
> > <snip>
> >
> > However, if we talking ourselves into copying x86 then perhaps we should
> > more accurately copy x86! Assuming I read the x86 code correctly then
> > crash_smp_send_stop() will (mostly) go staight to NMI rather
> > than trialling an IRQ first! That is not what is currently implemented
> > in the patch for arm64.
>
> Sure, I'm happy to change the patch to work that way, though I might
> wait to get some confirmation from a maintainer that they think this
> idea is worth pursuing before spending more time on it.

100%. Don't respin on my account.

> I don't think it would be hard to have the "crash stop" code jump
> straight to NMI if that's what people want. Matching x86 here seems
> reasonable, though I'd also say that my gut still says that even for
> crash stop we should try to stop things cleanly before jumping to NMI.
> I guess I could imagine that the code we're kexec-ing to generate the
> core file might be more likely to find the hardware in a funny state
> if we stopped CPUs w/ NMI vs IRQ.

In terms of the "right thing to do" for kdump then reviewing the s390
might be a good idea. Unfortunately it's a bit different to the other
arches and I can't offer a 95% answer about what that arch does.


Daniel.

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

  reply	other threads:[~2024-03-01 11:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08  1:02 [PATCH] arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI first Douglas Anderson
2024-01-09  0:54 ` Doug Anderson
2024-02-28  0:57   ` Doug Anderson
2024-02-28 13:11     ` Daniel Thompson
2024-02-29 18:34       ` Doug Anderson
2024-03-01 11:42         ` Daniel Thompson [this message]
2024-03-01 16:05     ` Mark Rutland
2024-03-04 17:34       ` Doug Anderson
2024-04-12 13:55 ` Will Deacon
2024-05-17 20:01   ` Doug Anderson
2024-06-24 13:49     ` Will Deacon
2024-05-17 20:01 ` Doug Anderson
2024-06-24 13:54   ` Will Deacon
2024-06-25 23:08     ` Doug Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240301114211.GC5795@aspen.lan \
    --to=daniel.thompson@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=dianders@chromium.org \
    --cc=frederic@kernel.org \
    --cc=gpiccoli@igalia.com \
    --cc=jpoimboe@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=misono.tomohiro@fujitsu.com \
    --cc=peterz@infradead.org \
    --cc=sumit.garg@linaro.org \
    --cc=swboyd@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vschneid@redhat.com \
    --cc=wens@csie.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox