On Thu, Dec 19, 2013 at 06:34:23PM +0900, Namhyung Kim wrote:
> From: Namhyung Kim <[email protected]>
>
> The trace_seq->state is for tracking errors during the use of
> trace_seq APIs and getting rid of die() in it.
>
> Signed-off-by: Namhyung Kim <[email protected]>
> ---
> tools/lib/traceevent/event-parse.h | 7 +++++++
> tools/lib/traceevent/trace-seq.c | 41 ++++++++++++++++++++++++++++++++++----
> 2 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/tools/lib/traceevent/event-parse.h b/tools/lib/traceevent/event-parse.h
> index cf5db9013f2c..3c890cb28db7 100644
> --- a/tools/lib/traceevent/event-parse.h
> +++ b/tools/lib/traceevent/event-parse.h
> @@ -58,6 +58,12 @@ struct pevent_record {
> #endif
> };
>
> +enum trace_seq_fail {
> + TRACE_SEQ__GOOD,
> + TRACE_SEQ__BUFFER_POISONED,
> + TRACE_SEQ__MEM_ALLOC_FAILED,
> +};
> +
> /*
> * Trace sequences are used to allow a function to call several other functions
> * to create a string of data to use (up to a max of PAGE_SIZE).
> @@ -68,6 +74,7 @@ struct trace_seq {
> unsigned int buffer_size;
> unsigned int len;
> unsigned int readpos;
> + enum trace_seq_fail state;
> };
>
> void trace_seq_init(struct trace_seq *s);
> diff --git a/tools/lib/traceevent/trace-seq.c b/tools/lib/traceevent/trace-seq.c
> index d7f2e68bc5b9..976ad2a146b3 100644
> --- a/tools/lib/traceevent/trace-seq.c
> +++ b/tools/lib/traceevent/trace-seq.c
> @@ -32,8 +32,8 @@
> #define TRACE_SEQ_POISON ((void *)0xdeadbeef)
> #define TRACE_SEQ_CHECK(s) \
> do { \
> - if ((s)->buffer == TRACE_SEQ_POISON) \
> - die("Usage of trace_seq after it was destroyed"); \
> + if ((s)->buffer == TRACE_SEQ_POISON) \
> + (s)->state = TRACE_SEQ__BUFFER_POISONED; \
So unless we use trace_seq_do_printf we dont have any
notification that this went wrong..?
How about use some sort of WARN_ONCE any time the state
is set != GOOD ?
thanks,
jirka
Hi Jiri,
On Fri, 3 Jan 2014 14:24:25 +0100, Jiri Olsa wrote:
> On Thu, Dec 19, 2013 at 06:34:23PM +0900, Namhyung Kim wrote:
>> From: Namhyung Kim <[email protected]>
>>
>> The trace_seq->state is for tracking errors during the use of
>> trace_seq APIs and getting rid of die() in it.
>>
>> Signed-off-by: Namhyung Kim <[email protected]>
>> ---
>> tools/lib/traceevent/event-parse.h | 7 +++++++
>> tools/lib/traceevent/trace-seq.c | 41 ++++++++++++++++++++++++++++++++++----
>> 2 files changed, 44 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/lib/traceevent/event-parse.h b/tools/lib/traceevent/event-parse.h
>> index cf5db9013f2c..3c890cb28db7 100644
>> --- a/tools/lib/traceevent/event-parse.h
>> +++ b/tools/lib/traceevent/event-parse.h
>> @@ -58,6 +58,12 @@ struct pevent_record {
>> #endif
>> };
>>
>> +enum trace_seq_fail {
>> + TRACE_SEQ__GOOD,
>> + TRACE_SEQ__BUFFER_POISONED,
>> + TRACE_SEQ__MEM_ALLOC_FAILED,
>> +};
>> +
>> /*
>> * Trace sequences are used to allow a function to call several other functions
>> * to create a string of data to use (up to a max of PAGE_SIZE).
>> @@ -68,6 +74,7 @@ struct trace_seq {
>> unsigned int buffer_size;
>> unsigned int len;
>> unsigned int readpos;
>> + enum trace_seq_fail state;
>> };
>>
>> void trace_seq_init(struct trace_seq *s);
>> diff --git a/tools/lib/traceevent/trace-seq.c b/tools/lib/traceevent/trace-seq.c
>> index d7f2e68bc5b9..976ad2a146b3 100644
>> --- a/tools/lib/traceevent/trace-seq.c
>> +++ b/tools/lib/traceevent/trace-seq.c
>> @@ -32,8 +32,8 @@
>> #define TRACE_SEQ_POISON ((void *)0xdeadbeef)
>> #define TRACE_SEQ_CHECK(s) \
>> do { \
>> - if ((s)->buffer == TRACE_SEQ_POISON) \
>> - die("Usage of trace_seq after it was destroyed"); \
>> + if ((s)->buffer == TRACE_SEQ_POISON) \
>> + (s)->state = TRACE_SEQ__BUFFER_POISONED; \
>
> So unless we use trace_seq_do_printf we dont have any
> notification that this went wrong..?
Right.
>
> How about use some sort of WARN_ONCE any time the state
> is set != GOOD ?
I'm not sure what's the right thing to do for that case. Printing a
warning message might disturb user's output since it can be in a middle
of some (other) processing and she doesn't want to print anything during
the processing for some reason.
I just thought that it's not so important to print message so keeps the
error internally until it gets printed. But I can be wrong as usual...
Thanks,
Namhyung
On Mon, Jan 06, 2014 at 04:44:18PM +0900, Namhyung Kim wrote:
SNIP
> >> + (s)->state = TRACE_SEQ__BUFFER_POISONED; \
> >
> > So unless we use trace_seq_do_printf we dont have any
> > notification that this went wrong..?
>
> Right.
>
> >
> > How about use some sort of WARN_ONCE any time the state
> > is set != GOOD ?
>
> I'm not sure what's the right thing to do for that case. Printing a
> warning message might disturb user's output since it can be in a middle
> of some (other) processing and she doesn't want to print anything during
> the processing for some reason.
>
> I just thought that it's not so important to print message so keeps the
> error internally until it gets printed. But I can be wrong as usual...
I think that if she manages to get one of those errors
the perf would fail soon anyway.. so it feels better
to print it out immediately.
jirka
On Mon, 6 Jan 2014 15:38:28 +0100
Jiri Olsa <[email protected]> wrote:
> > I just thought that it's not so important to print message so keeps the
> > error internally until it gets printed. But I can be wrong as usual...
>
> I think that if she manages to get one of those errors
> the perf would fail soon anyway.. so it feels better
> to print it out immediately.
Yeah, using a trace_seq after it has been destroyed is a critical
failure, and a major bug. A print to the user console should not be a
problem here. And actually, crashing is not that bad either, as glibc
does the same with using free() of a freed pointer.
But as this error is major, an unwanted print is minor.
-- Steve
Hi Steve and Jiri,
2014-01-06 PM 11:45, Steven Rostedt wrote:
> On Mon, 6 Jan 2014 15:38:28 +0100
> Jiri Olsa <[email protected]> wrote:
>
>
>>> I just thought that it's not so important to print message so keeps the
>>> error internally until it gets printed. But I can be wrong as usual...
>>
>> I think that if she manages to get one of those errors
>> the perf would fail soon anyway.. so it feels better
>> to print it out immediately.
>
> Yeah, using a trace_seq after it has been destroyed is a critical
> failure, and a major bug. A print to the user console should not be a
> problem here. And actually, crashing is not that bad either, as glibc
> does the same with using free() of a freed pointer.
>
> But as this error is major, an unwanted print is minor.
OK, I'll add the WARN_ONCE in the TRACE_SEQ_CHECK then.
Thanks,
Namhyung