On Mon, 4 Mar 2024 21:48:44 -0500
Mathieu Desnoyers wrote:
> On 2024-03-04 21:37, Steven Rostedt wrote:
> > On Mon, 4 Mar 2024 21:35:38 -0500
> > Steven Rostedt wrote:
> >
> >>> And it's not for debugging, it's for validation of assumptions
> >>> made about an upper bound limit defined for a
On 2024-03-04 21:37, Steven Rostedt wrote:
On Mon, 4 Mar 2024 21:35:38 -0500
Steven Rostedt wrote:
And it's not for debugging, it's for validation of assumptions
made about an upper bound limit defined for a compile-time
check, so as the code evolves issues are caught early.
validating is
On Mon, 4 Mar 2024 21:35:38 -0500
Steven Rostedt wrote:
> > And it's not for debugging, it's for validation of assumptions
> > made about an upper bound limit defined for a compile-time
> > check, so as the code evolves issues are caught early.
>
> validating is debugging.
Did Linus put you
On Mon, 4 Mar 2024 21:18:13 -0500
Mathieu Desnoyers wrote:
> On 2024-03-04 20:59, Steven Rostedt wrote:
> > On Mon, 4 Mar 2024 20:42:39 -0500
> > Mathieu Desnoyers wrote:
> >
> >> #define TRACE_OUTPUT_META_DATA_MAX_LEN 80
> >>
> >> and a runtime check in the code generating this
On 2024-03-04 20:59, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:42:39 -0500
Mathieu Desnoyers wrote:
#define TRACE_OUTPUT_META_DATA_MAX_LEN 80
and a runtime check in the code generating this header.
This would avoid adding an unchecked upper limit.
That would be a lot of complex
On Mon, 4 Mar 2024 20:42:39 -0500
Mathieu Desnoyers wrote:
> #define TRACE_OUTPUT_META_DATA_MAX_LEN80
>
> and a runtime check in the code generating this header.
>
> This would avoid adding an unchecked upper limit.
That would be a lot of complex code that is for debugging
On Mon, 4 Mar 2024 20:36:28 -0500
Mathieu Desnoyers wrote:
> > <...>-999 [001] . 2296.140373: tracing_mark_write:
> > hello
> > ^^^
> > This is the meta data that is added to trace_seq
>
> If this
On 2024-03-04 20:41, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:35:16 -0500
Steven Rostedt wrote:
BUILD_BUG_ON(TRACING_MARK_MAX_SIZE + sizeof(meta data stuff...) >
TRACE_SEQ_SIZE);
That's not the meta size I'm worried about. The sizeof(meta data) is the
raw event binary data, which is not
On Mon, 4 Mar 2024 20:35:16 -0500
Steven Rostedt wrote:
> > BUILD_BUG_ON(TRACING_MARK_MAX_SIZE + sizeof(meta data stuff...) >
> > TRACE_SEQ_SIZE);
>
> That's not the meta size I'm worried about. The sizeof(meta data) is the
> raw event binary data, which is not related to the size of the
On 2024-03-04 20:35, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:15:57 -0500
Mathieu Desnoyers wrote:
On 2024-03-04 19:27, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Since the size of trace_seq's buffer is the max an event can output, have
the trace_marker be half of the entire
On Mon, 4 Mar 2024 20:15:57 -0500
Mathieu Desnoyers wrote:
> On 2024-03-04 19:27, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > Since the size of trace_seq's buffer is the max an event can output, have
> > the trace_marker be half of the entire TRACE_SEQ_SIZE, which is 4K.
On 2024-03-04 19:27, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Since the size of trace_seq's buffer is the max an event can output, have
the trace_marker be half of the entire TRACE_SEQ_SIZE, which is 4K. That
will keep writes that has meta data written from being dropped (but
On Mon, 4 Mar 2024 16:43:46 -0800
Randy Dunlap wrote:
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 8198bfc54b58..d68544aef65f 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -7320,6 +7320,17 @@ tracing_mark_write(struct file *filp, const char
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8198bfc54b58..d68544aef65f 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -7320,6 +7320,17 @@ tracing_mark_write(struct file *filp, const char
> __user *ubuf,
> if ((ssize_t)cnt < 0)
>
From: "Steven Rostedt (Google)"
Since the size of trace_seq's buffer is the max an event can output, have
the trace_marker be half of the entire TRACE_SEQ_SIZE, which is 4K. That
will keep writes that has meta data written from being dropped (but
reported), because the total output of the print
15 matches
Mail list logo
