| Message ID | 20231209171058.78c1a026@gandalf.local.home (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | b55b0a0d7c4aa2dac3579aa7e6802d1f57445096 |
| Headers | show |
| Series | tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing | expand |
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