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.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable 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 AB095C433E0 for ; Tue, 16 Mar 2021 15:29:41 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1BB6D650EE for ; Tue, 16 Mar 2021 15:29:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1BB6D650EE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=W9gnynhY9f/FZAfjJMjX2s8DNrlEfZheWJXXkGE5Zg4=; b=Z9Buhrii7FzxeuWHyzKhY3B8H /Wy+eC7sKKsQEJjSKtY62Cpcq8Kay/lTYUPbyPdrGlDcPg8lojwMVRCyVTbTdoI3SBYllhHe2bxzs NykRjhM7HC3ZteViQBvjV+jbFddnYn3sWTYz7swVoT6uMyi6sqHVm5KlOkPZJCiTdai3iOJjbP2Wj RmdXIZtJYakpKscUiFwW8AS9+tu4MVGUYb2R8+tzvHunyoRAQc+ffVdwllAwhEXQpRCIrujs4CHiD jKpfrVHMRkULTNJD6V7vkBlBTStp7lYV6Ekc8tzaxFgnrWeLTlh+SiUXAfquhXY0i0Pkh5WnzfvpJ XryVlKjJw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lMBcE-00148Z-L7; Tue, 16 Mar 2021 15:28:14 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lMBc7-00145k-NQ for linux-arm-kernel@lists.infradead.org; Tue, 16 Mar 2021 15:28:10 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210316_152808_029396_9B19775E X-CRM114-Status: GOOD ( 27.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel