Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp448768rwd; Mon, 12 Jun 2023 16:38:22 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4XXIEoqzji8o67xdf7E3b4B2Znsi2lU6zfWday3Hsw2n6Rq4y9GKa//F38gWLBaK3sZ8FZ X-Received: by 2002:aa7:ccce:0:b0:514:a4da:408e with SMTP id y14-20020aa7ccce000000b00514a4da408emr5949658edt.2.1686613101886; Mon, 12 Jun 2023 16:38:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686613101; cv=none; d=google.com; s=arc-20160816; b=MCi7rRtEn0CeSm5no4AA62W3jzI6azeiP775G0f46gGxuf60UvKKkV3Uhaoy6aHwz3 ygDYNhNP29kU0+ESvrghzYZ8zD1i50lymyCQDNsoFHuDgZtIciaXCDcHQW90QIM2NrlM tPWyfuata41+vNwu3UZuoA7ubIFTA/qX2XfkhxA0Up6NQiTS3H6wk91AgRCSHBSlDufl oNUoVkOa0XXoxCdqu+6q2GTJYiD93JB4VzQZa1GfSkr/qn7ZQfYifuNxzL7K4xAPw9Et ZzIpF3smNQIsZYw8zUSO4/1CPTUS2hhADJ1lRTnkGK0Kh2onmRjKwdcmZwRdFHHzAW2W wCsA== 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 :message-id:subject:cc:to:from:date; bh=j1keufiV27FAKu45k70Mc0lBEdOlPeC810rTKRQKO7o=; b=KkpUx/h+pnJ53u8CThcOxPGwoik7fZvGFXbVwXFeuw70U+rOTyq3IldUSAHgYaEuGM urMhHfbJnnFkOfr71Ad+obbATEeBpfG2WcDG9wU9s1UGeNw8/d9iiDC5+KXo3DTKtlWO myXXdySH1IgG3dEoDFu/3RXLvNqxkRu5E8jacy0glh6zKVGdpfRh10IIK4ZxN/XdO8S7 XHrJJX2W7JgCwFWE/2qHTeH14asWRUQDydNqRkYB/CtYPWJpu2+BBRoT/JJaE4zdB2jP E38zAcOjX26droZXPMmedG0elreT8um8ygdcR9sjrk3ya/UUn671RCjrEN06A0Q9WFTY 3LGw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y25-20020aa7ccd9000000b00514b8932e37si6388291edt.54.2023.06.12.16.37.55; Mon, 12 Jun 2023 16:38:21 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237079AbjFLXdo (ORCPT + 99 others); Mon, 12 Jun 2023 19:33:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236781AbjFLXdm (ORCPT ); Mon, 12 Jun 2023 19:33:42 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0252510B; Mon, 12 Jun 2023 16:33:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8BE3061DC6; Mon, 12 Jun 2023 23:33:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68615C433D2; Mon, 12 Jun 2023 23:33:39 +0000 (UTC) Date: Mon, 12 Jun 2023 19:33:37 -0400 From: Steven Rostedt To: LKML , Linux Trace Kernel Cc: Masami Hiramatsu , Mark Rutland Subject: [PATCH] tracing: Add a debug_trace_printk() function Message-ID: <20230612193337.0fb0d3ca@gandalf.local.home> 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 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,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: X-Mailing-List: linux-kernel@vger.kernel.org From: "Steven Rostedt (Google)" While doing some tracing and kernel debugging, I found that some of my trace_printk()s were being lost in the noise of the other code that was being traced. Having a way to write trace_printk() not in the top level trace buffer would have been useful. There was also a time I needed to debug ftrace itself, where trace_printk() did not hit the paths that were being debugged. But because the trace that was being debugged, was going into the top level ring buffer, it was causing issues for seeing what is to be traced. To solve both of the above, add a debug_trace_printk() that can be used just like trace_printk() except that it goes into a "debug" instance buffer instead. This can be used at boot up as well. Signed-off-by: Steven Rostedt (Google) --- include/linux/kernel.h | 14 ++++++++++++++ kernel/trace/Kconfig | 20 ++++++++++++++++++++ kernel/trace/trace.c | 29 +++++++++++++++++++++++++++++ 3 files changed, 63 insertions(+) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 0d91e0af0125..594c9ba17fd4 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -432,6 +432,20 @@ __ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap); extern __printf(2, 0) int __ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap); +#ifdef CONFIG_FTRACE_DEBUG_PRINT +extern __printf(2,0) void do_debug_trace_printk(unsigned long ip, const char *fmt, ...); +#define debug_trace_printk(fmt, ...) \ +do { \ + do_debug_trace_printk(_THIS_IP_, fmt, ##__VA_ARGS__); \ +} while (0) + +extern void debug_tracing_stop(void); +#else +#define debug_trace_printk(fmt, ...) do { } while (0) +static inline void debug_tracing_stop(void) { } +#endif + + extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode); #else static inline void tracing_start(void) { } diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index abe5c583bd59..eb102070e9e6 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -974,6 +974,26 @@ config GCOV_PROFILE_FTRACE Note that on a kernel compiled with this config, ftrace will run significantly slower. +config FTRACE_DEBUG_PRINT + bool + depends on TRACING + help + This option enables the use of debug_trace_printk() instead of + using trace_printk(). The difference between the two is that + debug_trace_printk() traces are visible in the "debug" instance + found in: + + /sys/kernel/tracing/instances/debug + + This is useful when the trace printks should not interfere with + the normal top level tracing. It is also useful if the top level + tracing is very noisy and critical trace printks are dropped. + By using debug_trace_printk() the traces goes into as separate + ring buffer that will not be overridden by other trace events. + + If unsure say N (In fact, only say Y if you are debugging a + kernel and require this) + config FTRACE_SELFTEST bool diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 64a4dde073ef..c21a93cf5fd8 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -490,6 +490,10 @@ static struct trace_array global_trace = { .trace_flags = TRACE_DEFAULT_FLAGS, }; +#ifdef CONFIG_FTRACE_DEBUG_PRINT +static struct trace_array *debug_trace; +#endif + LIST_HEAD(ftrace_trace_arrays); int trace_array_get(struct trace_array *this_tr) @@ -10455,8 +10459,33 @@ void __init early_trace_init(void) tracer_alloc_buffers(); init_events(); + +#ifdef CONFIG_FTRACE_DEBUG_PRINT + debug_trace = trace_array_get_by_name("debug"); + if (WARN_ON(!debug_trace)) + return; + trace_array_init_printk(debug_trace); +#endif } +#ifdef CONFIG_FTRACE_DEBUG_PRINT +__printf(2, 0) +void do_debug_trace_printk(unsigned long ip, const char *fmt, ...) +{ + va_list ap; + + va_start(ap, fmt); + trace_array_vprintk(debug_trace, ip, fmt, ap); + va_end(ap); +} + +void debug_tracing_stop(void) +{ + debug_trace_printk("Stopping debug tracing\n"); + tracing_stop_tr(debug_trace); +} +#endif + void __init trace_init(void) { trace_event_init(); -- 2.39.2