Message ID | 20230601143109.v9.6.Ia3aeac89bb6751b682237e76e5ba594318e4b1aa@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp628421vqr; Thu, 1 Jun 2023 14:40:18 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5zTqLxlZ1f0b0Cf8jnWExdTNJKv1vb3M3316E+ldotnIqaD4ATzOv2imOek/sOYS6g2l9i X-Received: by 2002:a05:6a20:394a:b0:10e:457f:2548 with SMTP id r10-20020a056a20394a00b0010e457f2548mr8258233pzg.37.1685655618618; Thu, 01 Jun 2023 14:40:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685655618; cv=none; d=google.com; s=arc-20160816; b=yFePyu0+3TzEANdlWgBkt9ZpRlVmG6r3vaoie9bZk1m2KJgDy5myM8G2ru311xs0nn +IfImyY0gLRH6/nJgBB6dj+24g1eJoVVsAB8n8XB69AmNe/3DB/LHBcN2mRq43SmmKzL PtGNNyTTmXE2YeD8Hd3HR0vVkGUVSxpX0RqE75G//QS8xG1SE0vbkI7B/PZzBbNAPLIO 0ObcieqgtASt0c+bDlNT7ZM1ywvGhmbZscDLKE/8Nw/N3nYYzHX4Sv/vMp1nFpkQTJlu kJ8wgPec2uOavwPcT6AQHENq4upK+hWDCDTegKwsgLPuCEb+GWFnj+ECT6Qkvs59LdOW HF3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=MfGBHBvKGGFx2dApaWUV0FsGkRnAHULREps6A6RYWJ4=; b=puWezl9EnqpHCLmnnWQeVJzjNGoYUuvmg6mwicm0oXGEMgNcjU23LNG+gIeFMjEKi2 rC7DALlr9B7SGu34tDPLGT/6ftbzYjqXJUXKL6wQM+jax5PJvjRrbzV7UicBKDQdEHqX tFqeHM38DbyF2FqWN3qza3UteYHRKFfHKgBkr6bY1hqd0lFFdZcHkYeLIBiJTyZ0GiIe 5EYg0r9x+1KhNicxi6my9XpotNCHvyogHV7JIOBbsaxF+kWJscaocs4llthr+Z7mJ0cu DrzbinbWK3cRgPQMOp0x3amUgoZzMUx8cI7m7wPu67npazHJeVuUIRlmXxu/aKCDN/dV 4v3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=AkgOfxeq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i189-20020a639dc6000000b0053fb3c97be6si3349518pgd.838.2023.06.01.14.40.05; Thu, 01 Jun 2023 14:40:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=AkgOfxeq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233102AbjFAVhl (ORCPT <rfc822;limurcpp@gmail.com> + 99 others); Thu, 1 Jun 2023 17:37:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232971AbjFAVh1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 1 Jun 2023 17:37:27 -0400 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D3B9E40 for <linux-kernel@vger.kernel.org>; Thu, 1 Jun 2023 14:37:19 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-52c30fa5271so685699a12.0 for <linux-kernel@vger.kernel.org>; Thu, 01 Jun 2023 14:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1685655439; x=1688247439; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MfGBHBvKGGFx2dApaWUV0FsGkRnAHULREps6A6RYWJ4=; b=AkgOfxeqMJ+Uowmkx4hw7IQZ50qdy2xVCPyodSzFbID79vkX/uuep2hjtkAVQf+ZMY 2Ois27dY1aNRlYZc7JAHlkdtHKB/6T3f05uoIAoto3JEclpb7k9RtEHCD6+WC8K9AjHR 0/+O26QCTSXFLaWGDuAgWq5b1oezjD46LgHAY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685655439; x=1688247439; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MfGBHBvKGGFx2dApaWUV0FsGkRnAHULREps6A6RYWJ4=; b=N7HWJtLG4dL5P1bvft8Bpwy+A9annUOLMGKJWXlILXdsxka3YZxKrHUIzUd4SDECyT /R4ThtXT11aVK278FRcwrhr6ts2V1oix9YYk4NCMfq2TEjo1sOwteQtYQmSMiplTLo7O UnLmqUTwOyXWR0Oy6Go2eWuPkTqDbd2+OPsXw7GFt3aQa4GbUhHlFE3SJjmSbadf2Yns zT2NJwvdYrbv1cZ5ybz7E5vJMzzGnI4LnTs106VHipaR38+zOj79lIOGkmR3A/A5YKLI XXT8twiNeYsBlfAAN8C+dEsEF+nX8aSYFPmaoDJVGn2uomKUSxsqGYoQKk3Kzcobd6/n w7wQ== X-Gm-Message-State: AC+VfDzreSiaq2b3vy3VJGX/tQ6BgY+SUBB/CTXBN/1NpQPPRBsWPb4x IivrW8+wErqOQV/TnzXfFzrYUA== X-Received: by 2002:a05:6a20:1583:b0:10f:759d:c5b2 with SMTP id h3-20020a056a20158300b0010f759dc5b2mr8808767pzj.45.1685655438667; Thu, 01 Jun 2023 14:37:18 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:11b8:2d2:7e02:6bff]) by smtp.gmail.com with ESMTPSA id g22-20020aa78756000000b0064d48d98260sm5319534pfo.156.2023.06.01.14.37.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Jun 2023 14:37:18 -0700 (PDT) From: Douglas Anderson <dianders@chromium.org> To: Mark Rutland <mark.rutland@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Sumit Garg <sumit.garg@linaro.org>, Daniel Thompson <daniel.thompson@linaro.org>, Marc Zyngier <maz@kernel.org> Cc: linux-perf-users@vger.kernel.org, ito-yuichi@fujitsu.com, Chen-Yu Tsai <wens@csie.org>, Ard Biesheuvel <ardb@kernel.org>, Stephen Boyd <swboyd@chromium.org>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, linux-arm-kernel@lists.infradead.org, kgdb-bugreport@lists.sourceforge.net, Masayoshi Mizuma <msys.mizuma@gmail.com>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Lecopzer Chen <lecopzer.chen@mediatek.com>, Douglas Anderson <dianders@chromium.org>, Jason Wessel <jason.wessel@windriver.com>, linux-kernel@vger.kernel.org Subject: [PATCH v9 6/7] kgdb: Provide a stub kgdb_nmicallback() if !CONFIG_KGDB Date: Thu, 1 Jun 2023 14:31:50 -0700 Message-ID: <20230601143109.v9.6.Ia3aeac89bb6751b682237e76e5ba594318e4b1aa@changeid> X-Mailer: git-send-email 2.41.0.rc2.161.g9c6817b8e7-goog In-Reply-To: <20230601213440.2488667-1-dianders@chromium.org> References: <20230601213440.2488667-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767538026288319908?= X-GMAIL-MSGID: =?utf-8?q?1767538026288319908?= |
Series |
arm64: Add debug IPI for backtraces / kgdb; try to use NMI for it
|
|
Commit Message
Doug Anderson
June 1, 2023, 9:31 p.m. UTC
To save architectures from needing to wrap the call in #ifdefs, add a stub no-op version of kgdb_nmicallback(), which returns 1 if it didn't handle anything. Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> --- In v9 this is the only kgdb dependency. I'm assuming it could go through the arm64 tree? If that's not a good idea, we could always change the patch ("arm64: kgdb: Roundup cpus using IPI as NMI") not to depend on it by only calling kgdb_nmicallback() if CONFIG_KGDB is not defined. Changes in v9: - Added missing "inline" Changes in v8: - "Provide a stub kgdb_nmicallback() if !CONFIG_KGDB" new for v8 include/linux/kgdb.h | 1 + 1 file changed, 1 insertion(+)
Comments
Daniel, On Thu, Jun 1, 2023 at 2:37 PM Douglas Anderson <dianders@chromium.org> wrote: > > To save architectures from needing to wrap the call in #ifdefs, add a > stub no-op version of kgdb_nmicallback(), which returns 1 if it didn't > handle anything. > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > In v9 this is the only kgdb dependency. I'm assuming it could go > through the arm64 tree? If that's not a good idea, we could always > change the patch ("arm64: kgdb: Roundup cpus using IPI as NMI") not to > depend on it by only calling kgdb_nmicallback() if CONFIG_KGDB is not > defined. > > Changes in v9: > - Added missing "inline" > > Changes in v8: > - "Provide a stub kgdb_nmicallback() if !CONFIG_KGDB" new for v8 > > include/linux/kgdb.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > index 258cdde8d356..76e891ee9e37 100644 > --- a/include/linux/kgdb.h > +++ b/include/linux/kgdb.h > @@ -365,5 +365,6 @@ extern void kgdb_free_init_mem(void); > #define dbg_late_init() > static inline void kgdb_panic(const char *msg) {} > static inline void kgdb_free_init_mem(void) { } > +static inline int kgdb_nmicallback(int cpu, void *regs) { return 1; } What do you think about landing just ${SUBJECT} patch in kgdb right now so it can end up in v6.5-rc1? It seems like this series is currently blocked on Mark getting a spare moment and it seems unlikely that'll happen this cycle. If we at least land the kgdb patch then it would make things all that much easier to land in the next cycle. The kgdb patch feels like it can make sense on its own... -Doug
On Thu, Jun 15, 2023 at 11:14:18AM -0700, Doug Anderson wrote: > Daniel, > > On Thu, Jun 1, 2023 at 2:37 PM Douglas Anderson <dianders@chromium.org> wrote: > > > > To save architectures from needing to wrap the call in #ifdefs, add a > > stub no-op version of kgdb_nmicallback(), which returns 1 if it didn't > > handle anything. > > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > --- > > In v9 this is the only kgdb dependency. I'm assuming it could go > > through the arm64 tree? If that's not a good idea, we could always > > change the patch ("arm64: kgdb: Roundup cpus using IPI as NMI") not to > > depend on it by only calling kgdb_nmicallback() if CONFIG_KGDB is not > > defined. > > > > Changes in v9: > > - Added missing "inline" > > > > Changes in v8: > > - "Provide a stub kgdb_nmicallback() if !CONFIG_KGDB" new for v8 > > > > include/linux/kgdb.h | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > > index 258cdde8d356..76e891ee9e37 100644 > > --- a/include/linux/kgdb.h > > +++ b/include/linux/kgdb.h > > @@ -365,5 +365,6 @@ extern void kgdb_free_init_mem(void); > > #define dbg_late_init() > > static inline void kgdb_panic(const char *msg) {} > > static inline void kgdb_free_init_mem(void) { } > > +static inline int kgdb_nmicallback(int cpu, void *regs) { return 1; } > > What do you think about landing just ${SUBJECT} patch in kgdb right > now so it can end up in v6.5-rc1? It seems like this series is > currently blocked on Mark getting a spare moment and it seems unlikely > that'll happen this cycle. If we at least land the kgdb patch then it > would make things all that much easier to land in the next cycle. The > kgdb patch feels like it can make sense on its own... Yes, grabbing this one should be fine! Daniel.
On Thu, Jun 01, 2023 at 02:31:50PM -0700, Douglas Anderson wrote: > To save architectures from needing to wrap the call in #ifdefs, add a > stub no-op version of kgdb_nmicallback(), which returns 1 if it didn't > handle anything. > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > In v9 this is the only kgdb dependency. I'm assuming it could go > through the arm64 tree? If that's not a good idea, we could always > change the patch ("arm64: kgdb: Roundup cpus using IPI as NMI") not to > depend on it by only calling kgdb_nmicallback() if CONFIG_KGDB is not > defined. > > Changes in v9: > - Added missing "inline" > > Changes in v8: > - "Provide a stub kgdb_nmicallback() if !CONFIG_KGDB" new for v8 > > include/linux/kgdb.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > index 258cdde8d356..76e891ee9e37 100644 > --- a/include/linux/kgdb.h > +++ b/include/linux/kgdb.h > @@ -365,5 +365,6 @@ extern void kgdb_free_init_mem(void); > #define dbg_late_init() > static inline void kgdb_panic(const char *msg) {} > static inline void kgdb_free_init_mem(void) { } > +static inline int kgdb_nmicallback(int cpu, void *regs) { return 1; } Is '1' an error? Can we return an actual error code if so? It makes it *much* clearer to anyone looking at the code. Thanks, Mark. > #endif /* ! CONFIG_KGDB */ > #endif /* _KGDB_H_ */ > -- > 2.41.0.rc2.161.g9c6817b8e7-goog >
On Mon, Aug 07, 2023 at 11:27:00AM +0100, Mark Rutland wrote: > On Thu, Jun 01, 2023 at 02:31:50PM -0700, Douglas Anderson wrote: > > +static inline int kgdb_nmicallback(int cpu, void *regs) { return 1; } > > Is '1' an error? > > Can we return an actual error code if so? It makes it *much* clearer to anyone > looking at the code. Never mind; I see this was already queued. Sorry for the noise. Thanks, Mark.
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h index 258cdde8d356..76e891ee9e37 100644 --- a/include/linux/kgdb.h +++ b/include/linux/kgdb.h @@ -365,5 +365,6 @@ extern void kgdb_free_init_mem(void); #define dbg_late_init() static inline void kgdb_panic(const char *msg) {} static inline void kgdb_free_init_mem(void) { } +static inline int kgdb_nmicallback(int cpu, void *regs) { return 1; } #endif /* ! CONFIG_KGDB */ #endif /* _KGDB_H_ */