Message ID | 20231209171058.78c1a026@gandalf.local.home |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp6258973vqy; Sat, 9 Dec 2023 14:10:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IF8ufsbn+yJuX/glmuiL75Sgjf3DmEavM9Cj74saIFkkKD2B0TC1gRyucJcqSRDIg7Oys/X X-Received: by 2002:a05:6e02:1a4d:b0:35d:59a2:2b4 with SMTP id u13-20020a056e021a4d00b0035d59a202b4mr3971032ilv.84.1702159847031; Sat, 09 Dec 2023 14:10:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702159847; cv=none; d=google.com; s=arc-20160816; b=SEWj7QzGdtpdzuPwait3MrvjR7ZTJqXkdei/d0GkvyHTO0YH52BdAUW/PK03CCtnUn Qxe7VZdm7OfGAV9JxYN2EKrAoiuI587GaChxykoLblFGk8YZ6PWsx9CTiqQ/j01tU/Jt ysCjwBiIjLpI3jg6K0ahoh911bPUtPHVjWt0TvTgJ79NEGASePeurc1vhK0A+cABdooT lycKacrIb3Tg/0cbs5qCVzEsrMziirzOhk17d8XpXdDxiwNG4M3XhSpOJkHMhH0WJVsY lnsQ0qfNf+8ZZ/OomNfBsnYZfOU6GX1+mAeCifmg35HwP4U2NaBKS+e/cr2f6T5Hql6R halQ== 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=rKfV38E36hWTSO33q9Uxt8yFswZ1po1Ma3tV5WnQG28=; fh=R8JZsVKDlS7lXIAvTNV55bsjlDBI0i4sqiOYXO4tZQA=; b=JJpw9Atw7nCLD9dLsAcgSboUvb7Zk4TEY9L8qYVmf9vB8fibfDvP3N7AQfBlZpkWin IO4Giv69W3jxS2DRZ9HinDta/LRTDLp59R+9nirxC2Sv3n1eybiBqiVGtlFhFhsuBPtI wQM0XCxesgLrwO6+NbJB2jIY93POSG2B+k7Vajl+9cvbppD2smB/PDOrU8/2rjDF+gay G+9Y1fRElnYFRfBEHcCHRvvEBEAXax51Aq71ZVIc6efLqJoCg76DH4o0juC+gbNaBCnE hyTdUmMBAqBUB6lIW95MjQ6+rqazBj9V6KL0gfpcCSEOC8uYxoYGnO2ol3H5b7nw0Hk6 okfA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id s15-20020a65690f000000b005c6c1edaaa5si3618438pgq.520.2023.12.09.14.10.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Dec 2023 14:10:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 18DC180613A3; Sat, 9 Dec 2023 14:10:41 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231260AbjLIWKS (ORCPT <rfc822;kartikey406@gmail.com> + 99 others); Sat, 9 Dec 2023 17:10:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229477AbjLIWKR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 9 Dec 2023 17:10:17 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50DC7125 for <linux-kernel@vger.kernel.org>; Sat, 9 Dec 2023 14:10:24 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A4D4C433C7; Sat, 9 Dec 2023 22:10:23 +0000 (UTC) Date: Sat, 9 Dec 2023 17:10:58 -0500 From: Steven Rostedt <rostedt@goodmis.org> To: LKML <linux-kernel@vger.kernel.org>, Linux Trace Kernel <linux-trace-kernel@vger.kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Subject: [PATCH] tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing Message-ID: <20231209171058.78c1a026@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (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=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Sat, 09 Dec 2023 14:10:41 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784843963814128663 X-GMAIL-MSGID: 1784843963814128663 |
Series |
tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing
|
|
Commit Message
Steven Rostedt
Dec. 9, 2023, 10:10 p.m. UTC
From: "Steven Rostedt (Google)" <rostedt@goodmis.org> If a large event was added to the ring buffer that is larger than what the trace_seq can handle, it just drops the output: ~# cat /sys/kernel/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 2/2 #P:8 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | <...>-859 [001] ..... 141.118951: tracing_mark_write <...>-859 [001] ..... 141.148201: tracing_mark_write: 78901234 Instead, catch this case and add some context: ~# cat /sys/kernel/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 2/2 #P:8 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | <...>-852 [001] ..... 121.550551: tracing_mark_write[LINE TOO BIG] <...>-852 [001] ..... 121.550581: tracing_mark_write: 78901234 This now emulates the same output as trace_pipe. Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> --- kernel/trace/trace.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On 2023-12-09 17:10, Steven Rostedt wrote: [...] > <...>-852 [001] ..... 121.550551: tracing_mark_write[LINE TOO BIG] > <...>-852 [001] ..... 121.550581: tracing_mark_write: 78901234 Failing to print an entire message because it does not fit in the buffer size is rather inconvenient. It would be better to print the partial line, and end the line with a <TRUNCATED LINE> tag. Thanks, Mathieu
On Sun, 10 Dec 2023 09:11:40 -0500 Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > On 2023-12-09 17:10, Steven Rostedt wrote: > [...] > > <...>-852 [001] ..... 121.550551: tracing_mark_write[LINE TOO BIG] > > <...>-852 [001] ..... 121.550581: tracing_mark_write: 78901234 > > Failing to print an entire message because it does not fit in the > buffer size is rather inconvenient. Yes I agree, and luckily it hasn't been called out as an issue. Note, I hit this because I extended the trace_marker buffer before increasing the trace_seq size. Otherwise, the trace_marker just breaks it up. This can now only be triggered by internal changes. > > It would be better to print the partial line, and end the line with > a <TRUNCATED LINE> tag. Agreed, but I don't have time to do that (I already spent way too much time on this than I had allocated). I decided to just do what the trace_pipe currently does, and leave "print partial line" to another day when I can allocate time on this. Hmm, this could be added to the "TODO" list that was talked about in ksummit-discuss. -- Steve
On Sun, 10 Dec 2023 10:34:15 -0500 Steven Rostedt <rostedt@goodmis.org> wrote: > On Sun, 10 Dec 2023 09:11:40 -0500 > Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > > On 2023-12-09 17:10, Steven Rostedt wrote: > > [...] > > > <...>-852 [001] ..... 121.550551: tracing_mark_write[LINE TOO BIG] > > > <...>-852 [001] ..... 121.550581: tracing_mark_write: 78901234 > > > > Failing to print an entire message because it does not fit in the > > buffer size is rather inconvenient. > > Yes I agree, and luckily it hasn't been called out as an issue. Note, I hit > this because I extended the trace_marker buffer before increasing the > trace_seq size. Otherwise, the trace_marker just breaks it up. This can now > only be triggered by internal changes. Rather than the broken output, I would perfer this output. > > > > > It would be better to print the partial line, and end the line with > > a <TRUNCATED LINE> tag. But how long the partial line length is good enough? I think that big (and long) user marker maybe not for human, so we don't need to care about readability. I think current one is one of better solutions. So I'll give my Reviewed-by. :) Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Thank you, > > Agreed, but I don't have time to do that (I already spent way too much time > on this than I had allocated). I decided to just do what the trace_pipe > currently does, and leave "print partial line" to another day when I can > allocate time on this. > > Hmm, this could be added to the "TODO" list that was talked about in > ksummit-discuss. > > -- Steve >
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index fbcd3bafb93e..aa8f99f3e5de 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -4722,7 +4722,11 @@ static int s_show(struct seq_file *m, void *v) iter->leftover = ret; } else { - print_trace_line(iter); + ret = print_trace_line(iter); + if (ret == TRACE_TYPE_PARTIAL_LINE) { + iter->seq.full = 0; + trace_seq_puts(&iter->seq, "[LINE TOO BIG]\n"); + } ret = trace_print_seq(m, &iter->seq); /* * If we overflow the seq_file buffer, then it will