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 X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0C47C433DB for ; Tue, 16 Mar 2021 15:29:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BA30E64FE8 for ; Tue, 16 Mar 2021 15:29:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236677AbhCPP2b (ORCPT ); Tue, 16 Mar 2021 11:28:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:41034 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233595AbhCPP2E (ORCPT ); Tue, 16 Mar 2021 11:28:04 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9CDC9650E4; Tue, 16 Mar 2021 15:28:02 +0000 (UTC) Date: Tue, 16 Mar 2021 11:28:00 -0400 From: Steven Rostedt To: Mark Brown Cc: Sangmoon Kim , Catalin Marinas , Will Deacon , jordan.lim@samsung.com, Ingo Molnar , Dave Martin , Mark Rutland , Dmitry Safonov <0x7f454c46@gmail.com>, Amit Daniel Kachhap , Peter Collingbourne , Gavin Shan , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: traps: add tracepoints for unusal exception cases Message-ID: <20210316112800.3617ffd7@gandalf.local.home> In-Reply-To: <20210308133149.GA4656@sirena.org.uk> References: <20210305123635.27492-1-sangmoon.kim@samsung.com> <20210308133149.GA4656@sirena.org.uk> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Mar 2021 13:31:49 +0000 Mark Brown wrote: > > @@ -832,6 +846,7 @@ void __noreturn arm64_serror_panic(struct pt_regs *regs, u32 esr) > > if (regs) > > __show_regs(regs); > > > > + trace_traps_serror_panic_tp(regs, esr); > > nmi_panic(regs, "Asynchronous SError Interrupt"); > > One of the concerns people have with adding tracepoints is that they can > end up defining ABI so if we *are* going to add any then we need to > think carefully about how they're defined. As things currently stand > they'll pass in the full pt_regs struct which includes not only what's > defined by the hardware but also additional software defined information > we store along with it like the stackframe which would be even more of a > problem if it ends up getting used by someone in a way that ends up as > ABI. These are defined as bare tracehooks which does mitigate against > things ending up getting used in ways that cause problems but people are > still going to worry about things ending up getting relied on one way or > another. > > That said it's not clear to me that this will record anything beyond the > pointer directly in the trace buffer so the value might not be useful > for terribly long, that itself feels like it might not be as robust an > interface as it should be. BTW, we are working on an "event probe". That is similar to kprobe event, but attaches to the output of an event to create another event. Thus, if you had a trace event that was like this: trace_regs(pt_regs *regs); Where you save the regs pointer for output: TP_STRUCT__entry( __field(void *, regs ) ), TP_fast_assign( __entry->regs = regs; ) Then you would be able to get access to all the regs for that tracepoint! # echo 'e:pt_regs regs ip=+8(regs):x64' > /sys/kernel/tracing/kprobe_events Where "e:" denotes that this connects to a trace event, "pt_regs" is the event name created under kprobes subsystem, "regs" is the trace event to attach to, "ip=" is what will be printed, and "+8(regs):x64" is a way to dereference the regs pointer at the time of the trace event is executed. That is, it will dereference 8 bytes from the pointer and return a x64 hex number. Thus, trace events like this may be very useful in the near future. -- Steve