From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 210E2C77B7C for ; Wed, 10 May 2023 16:30:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229727AbjEJQat (ORCPT ); Wed, 10 May 2023 12:30:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbjEJQao (ORCPT ); Wed, 10 May 2023 12:30:44 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5BFF24207; Wed, 10 May 2023 09:30:43 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9AA5212FC; Wed, 10 May 2023 09:31:27 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.32.173]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 700EB3F67D; Wed, 10 May 2023 09:30:35 -0700 (PDT) Date: Wed, 10 May 2023 17:30:32 +0100 From: Mark Rutland To: Doug Anderson Cc: Catalin Marinas , Will Deacon , Sumit Garg , Daniel Thompson , Marc Zyngier , ito-yuichi@fujitsu.com, kgdb-bugreport@lists.sourceforge.net, Chen-Yu Tsai , Masayoshi Mizuma , Peter Zijlstra , Ard Biesheuvel , "Rafael J . Wysocki" , linux-arm-kernel@lists.infradead.org, Stephen Boyd , Lecopzer Chen , Thomas Gleixner , linux-perf-users@vger.kernel.org, Alexandru Elisei , Andrey Konovalov , Ben Dooks , Borislav Petkov , Christophe Leroy , "Darrick J. Wong" , Dave Hansen , "David S. Miller" , "Eric W. Biederman" , Frederic Weisbecker , Gaosheng Cui , "Gautham R. Shenoy" , Greg Kroah-Hartman , "Guilherme G. Piccoli" , Guo Ren , "H. Peter Anvin" , Huacai Chen , Ingo Molnar , Ingo Molnar , "Jason A. Donenfeld" , Jason Wessel , Jianmin Lv , Jiaxun Yang , Jinyang He , Joey Gouly , Kees Cook , Laurent Dufour , Masahiro Yamada , Masayoshi Mizuma , Michael Ellerman , Nicholas Piggin , "Paul E. McKenney" , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Pierre Gondois , Qing Zhang , "Russell King (Oracle)" , Russell King , Thomas Bogendoerfer , Ulf Hansson , WANG Xuerui , linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, sparclinux@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v8 00/10] arm64: Add framework to turn an IPI as NMI Message-ID: References: <20230419225604.21204-1-dianders@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 10, 2023 at 08:28:17AM -0700, Doug Anderson wrote: > Hi, Hi Doug, > On Wed, Apr 19, 2023 at 3:57 PM Douglas Anderson 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). > 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 FWIW, there are still longstanding soundness issues in the arm64 pseudo-NMI support (and fixing that requires an overhaul of our DAIF / IRQ flag management, which I've been chipping away at for a number of releases), so I hadn't looked at this in detail yet because the foundations are still somewhat dodgy. I appreciate that this has been around for a while, and it's on my queue to look at. Thanks, Mark.