Received-SPF: pass (google.com: domain of linux-kernel+bounces-91014-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20231207170251.1.Id4817adef610302554b8aa42b090d57270dc119c@changeid>
 <CAD=FV=WtJCkdSY=HYDmBjn3hc4TYT7j0bMxGCV-=B3o3bm-kpQ@mail.gmail.com>
 <CAD=FV=XMkrWmA1D6UjdTs8oZiXxKc1xiUoRqtNqAE-7GoPk8mA@mail.gmail.com> <ZeH81_k6TFk7W4tm@FVFF77S0Q05N>
In-Reply-To: <ZeH81_k6TFk7W4tm@FVFF77S0Q05N>
From: Doug Anderson <dianders@chromium.org>
Date: Mon, 4 Mar 2024 09:34:19 -0800
Message-ID: <CAD=FV=XJhvVO7k0hhz_KPH4eSrJQdb+k2CJQeCAP40+PYAdDBg@mail.gmail.com>
Subject: Re: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send_stop()
 should try non-NMI first
To: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, 
	Marc Zyngier <maz@kernel.org>, Misono Tomohiro <misono.tomohiro@fujitsu.com>, 
	Chen-Yu Tsai <wens@csie.org>, Stephen Boyd <swboyd@chromium.org>, 
	Daniel Thompson <daniel.thompson@linaro.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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Mar 1, 2024 at 8:06=E2=80=AFAM Mark Rutland <mark.rutland@arm.com> =
wrote:
>
> Hi Doug,
>
> On Tue, Feb 27, 2024 at 04:57:31PM -0800, Doug Anderson wrote:
> > On Mon, Jan 8, 2024 at 4:54=E2=80=AFPM Doug Anderson <dianders@chromium=
org> wrote:
> > > On Thu, Dec 7, 2023 at 5:03=E2=80=AFPM Douglas Anderson <dianders@chr=
omium.org> wrote:
>
> > > The sound of crickets is overwhelming. ;-) Does anyone have any
> > > comments here? Is this a terrible idea? Is this the best idea you've
> > > heard all year (it's only been 8 days, so maybe)? Is this great but
> > > the implementation is lacking (at best)? Do you hate that this waits
> > > for 1 second and wish it waited for 1 ms? 10 ms? 100 ms? 8192 ms?
> > >
> > > Aside from the weirdness of a processor being killed while holding th=
e
> > > console lock, it does seem beneficial to give IRQs at least a little
> > > time to finish before killing a processor. I don't have any other
> > > explicit examples, but I could just imagine that things might be a
> > > little more orderly in such a case...
> >
> > 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.
> >
> > FWIW the serial console dumping issue that originally inspired me to
> > track this down has been worked around at least well enough to not
> > spew garbage in my console. See commit 9e957a155005 ("serial:
> > qcom-geni: Don't cancel/abort if we can't get the port lock"). It's
> > still a little awkward because we'll be running fully lockless during
> > panic time, but it seems to work...
>
> This is on my list of things to look into, but I haven't had the chance t=
o go
> through it in detail.
>
> From a high level, I think this sounds reasonable; I just want to make su=
re
> this doesn't lead to any new surprises...

Sounds good. For now I'll snooze this for another 2 months and if I
haven't heard from you then I'll pester you again. There's no crazy
hurry, I was just hoping for some sort of decision one way or the
other. For now I'll hold off on changing things to match x86 exactly
until I get your take on it too.

-Doug