linux-kernel - Re: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send

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: <CAD=FV=XJhvVO7k0hhz_KPH4eSrJQdb+k2CJQeCAP40+PYAdDBg@mail.gmail.com>
Date: Mon, 4 Mar 2024 09:34:19 -0800
From: Doug Anderson <dianders@...omium.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, 
	Marc Zyngier <maz@...nel.org>, Misono Tomohiro <misono.tomohiro@...itsu.com>, 
	Chen-Yu Tsai <wens@...e.org>, Stephen Boyd <swboyd@...omium.org>, 
	Daniel Thompson <daniel.thompson@...aro.org>, Sumit Garg <sumit.garg@...aro.org>, 
	Frederic Weisbecker <frederic@...nel.org>, "Guilherme G. Piccoli" <gpiccoli@...lia.com>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Kees Cook <keescook@...omium.org>, 
	Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Tony Luck <tony.luck@...el.com>, Valentin Schneider <vschneid@...hat.com>, 
	linux-arm-kernel@...ts.infradead.org, linux-hardening@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send_stop()
 should try non-NMI first

Hi,

On Fri, Mar 1, 2024 at 8:06 AM Mark Rutland <mark.rutland@....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 PM Doug Anderson <dianders@...omiumorg> wrote:
> > > On Thu, Dec 7, 2023 at 5:03 PM Douglas Anderson <dianders@...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 the
> > > 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 to go
> through it in detail.
>
> From a high level, I think this sounds reasonable; I just want to make sure
> 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