| 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
| ||
|
Message-ID: <CAD=FV=Wny=iFQf2GGuC2qP9hy4FHzpiRpV=ZvxEW77DX02XGzQ@mail.gmail.com>
Date: Wed, 10 May 2023 08:28:17 -0700
From: Doug Anderson <dianders@...omium.org>
To: 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>,
Mark Rutland <mark.rutland@....com>
Cc: ito-yuichi@...itsu.com, kgdb-bugreport@...ts.sourceforge.net,
Chen-Yu Tsai <wens@...e.org>,
Masayoshi Mizuma <msys.mizuma@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Ard Biesheuvel <ardb@...nel.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
linux-arm-kernel@...ts.infradead.org,
Stephen Boyd <swboyd@...omium.org>,
Lecopzer Chen <lecopzer.chen@...iatek.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-perf-users@...r.kernel.org,
Alexandru Elisei <alexandru.elisei@....com>,
Andrey Konovalov <andreyknvl@...il.com>,
Ben Dooks <ben-linux@...ff.org>,
Borislav Petkov <bp@...en8.de>,
Christophe Leroy <christophe.leroy@...roup.eu>,
"Darrick J. Wong" <djwong@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"David S. Miller" <davem@...emloft.net>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Frederic Weisbecker <frederic@...nel.org>,
Gaosheng Cui <cuigaosheng1@...wei.com>,
"Gautham R. Shenoy" <gautham.shenoy@....com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Guilherme G. Piccoli" <gpiccoli@...lia.com>,
Guo Ren <guoren@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
Huacai Chen <chenhuacai@...nel.org>,
Ingo Molnar <mingo@...nel.org>, Ingo Molnar <mingo@...hat.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Jason Wessel <jason.wessel@...driver.com>,
Jianmin Lv <lvjianmin@...ngson.cn>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Jinyang He <hejinyang@...ngson.cn>,
Joey Gouly <joey.gouly@....com>,
Kees Cook <keescook@...omium.org>,
Laurent Dufour <ldufour@...ux.ibm.com>,
Masahiro Yamada <masahiroy@...nel.org>,
Masayoshi Mizuma <m.mizuma@...fujitsu.com>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Philippe Mathieu-Daudé <f4bug@...at.org>,
Pierre Gondois <Pierre.Gondois@....com>,
Qing Zhang <zhangqing@...ngson.cn>,
"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
Russell King <linux@...linux.org.uk>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Ulf Hansson <ulf.hansson@...aro.org>,
WANG Xuerui <kernel@...0n.name>, linux-kernel@...r.kernel.org,
linux-mips@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
loongarch@...ts.linux.dev, sparclinux@...r.kernel.org,
x86@...nel.org
Subject: Re: [PATCH v8 00/10] arm64: Add framework to turn an IPI as NMI
Hi,
On Wed, Apr 19, 2023 at 3:57 PM Douglas Anderson <dianders@...omium.org> wrote:
>
> This is an attempt to resurrect Sumit's old patch series [1] that
> allowed us to use the arm64 pseudo-NMI to get backtraces of CPUs and
> also to round up CPUs in kdb/kgdb. The last post from Sumit that I
> could find was v7, so I called this series v8. I haven't copied all of
> his old changelongs here, but you can find them from the link.
>
> Since v7, I have:
> * Addressed the small amount of feedback that was there for v7.
> * Rebased.
> * Added a new patch that prevents us from spamming the logs with idle
> tasks.
> * Added an extra patch to gracefully fall back to regular IPIs if
> pseudo-NMIs aren't there.
>
> Since there appear to be a few different patches series related to
> being able to use NMIs to get stack traces of crashed systems, let me
> try to organize them to the best of my understanding:
>
> a) This series. On its own, a) will (among other things) enable stack
> traces of all running processes with the soft lockup detector if
> you've enabled the sysctl "kernel.softlockup_all_cpu_backtrace". On
> its own, a) doesn't give a hard lockup detector.
>
> b) A different recently-posted series [2] that adds a hard lockup
> detector based on perf. On its own, b) gives a stack crawl of the
> locked up CPU but no stack crawls of other CPUs (even if they're
> locked too). Together with a) + b) we get everything (full lockup
> detect, full ability to get stack crawls).
>
> c) The old Android "buddy" hard lockup detector [3] that I'm
> considering trying to upstream. If b) lands then I believe c) would
> be redundant (at least for arm64). c) on its own is really only
> useful on arm64 for platforms that can print CPU_DBGPCSR somehow
> (see [4]). a) + c) is roughly as good as a) + b).
>
> [1] https://lore.kernel.org/linux-arm-kernel/1604317487-14543-1-git-send-email-sumit.garg@linaro.org/
> [2] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/
> [3] https://issuetracker.google.com/172213097
> [4] https://issuetracker.google.com/172213129
>
> Changes in v8:
> - dynamic_ipi_setup() and dynamic_ipi_teardown() no longer take cpu param
> - dynamic_ipi_setup() and dynamic_ipi_teardown() no longer take cpu param
> - Add loongarch support, too
> - Removed "#ifdef CONFIG_SMP" since arm64 is always SMP
> - "Tag the arm64 idle functions as __cpuidle" new for v8
> - "Provide a stub kgdb_nmicallback() if !CONFIG_KGDB" new for v8
> - "Fallback to a regular IPI if NMI isn't enabled" new for v8
>
> Douglas Anderson (3):
> arm64: idle: Tag the arm64 idle functions as __cpuidle
> kgdb: Provide a stub kgdb_nmicallback() if !CONFIG_KGDB
> arm64: ipi_nmi: Fallback to a regular IPI if NMI isn't enabled
>
> Sumit Garg (7):
> arm64: Add framework to turn IPI as NMI
> irqchip/gic-v3: Enable support for SGIs to act as NMIs
> arm64: smp: Assign and setup an IPI as NMI
> nmi: backtrace: Allow runtime arch specific override
> arm64: ipi_nmi: Add support for NMI backtrace
> kgdb: Expose default CPUs roundup fallback mechanism
> arm64: kgdb: Roundup cpus using IPI as NMI
>
> arch/arm/include/asm/irq.h | 2 +-
> arch/arm/kernel/smp.c | 3 +-
> arch/arm64/include/asm/irq.h | 4 ++
> arch/arm64/include/asm/nmi.h | 17 +++++
> arch/arm64/kernel/Makefile | 2 +-
> arch/arm64/kernel/idle.c | 4 +-
> arch/arm64/kernel/ipi_nmi.c | 103 +++++++++++++++++++++++++++++++
> arch/arm64/kernel/kgdb.c | 18 ++++++
> arch/arm64/kernel/smp.c | 8 +++
> arch/loongarch/include/asm/irq.h | 2 +-
> arch/loongarch/kernel/process.c | 3 +-
> arch/mips/include/asm/irq.h | 2 +-
> arch/mips/kernel/process.c | 3 +-
> arch/powerpc/include/asm/nmi.h | 2 +-
> arch/powerpc/kernel/stacktrace.c | 3 +-
> arch/sparc/include/asm/irq_64.h | 2 +-
> arch/sparc/kernel/process_64.c | 4 +-
> arch/x86/include/asm/irq.h | 2 +-
> arch/x86/kernel/apic/hw_nmi.c | 3 +-
> drivers/irqchip/irq-gic-v3.c | 29 ++++++---
> include/linux/kgdb.h | 13 ++++
> include/linux/nmi.h | 12 ++--
> kernel/debug/debug_core.c | 8 ++-
> 23 files changed, 217 insertions(+), 32 deletions(-)
It's been 3 weeks and I haven't heard a peep on this series. That
means nobody has any objections and it's all good to land, right?
Right? :-P
Seriously, though, I really think we should figure out how to get this
landed. There's obviously interest from several different parties and
I'm chomping at the bit waiting to spin this series according to your
wishes. I also don't think there's anything super scary/ugly here. IMO
the ideal situation is that folks are OK with the idea presented in
the last patch in the series ("arm64: ipi_nmi: Fallback to a regular
IPI if NMI isn't enabled") and then I can re-spin this series to be
_much_ simpler. That being said, I'm also OK with dropping that patch
and starting the discussion for how to land the rest of the patches in
the series.
Please let me know!
-Doug
Powered by blists - more mailing lists