[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150717132439.689f8cc8@gandalf.local.home>
Date: Fri, 17 Jul 2015 13:24:39 -0400
From: Sara Rostedt <sara@...e.goodmis.org>
To: He Kuang <hekuang@...wei.com>, Javi Merino <javi.merino@....com>
Cc: <ast@...mgrid.com>, <masami.hiramatsu.pt@...achi.com>,
<acme@...nel.org>, <a.p.zijlstra@...llo.nl>, <mingo@...hat.com>,
<namhyung@...nel.org>, <jolsa@...nel.org>, <wangnan0@...wei.com>,
<pi3orama@....com>, <linux-kernel@...r.kernel.org>,
Alex Bennée
<alex.bennee@...aro.org>, Dave Martin <Dave.Martin@....com>
Subject: Re: [RFC PATCH v4 1/3] tracing/events: Fix wrong sample output by
storing array length instead of size
On Fri, 17 Jul 2015 10:32:15 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> > @@ -453,7 +454,7 @@ trace_event_define_fields_##call(struct trace_event_call *event_call) \
> > __item_length = (len) * sizeof(type); \
> > __data_offsets->item = __data_size + \
> > offsetof(typeof(*entry), __data); \
> > - __data_offsets->item |= __item_length << 16; \
> > + __data_offsets->item |= (len) << 16; \
>
> This change affects all callers of dymanic_array, not just bitmasks.
This also affects what goes into the trace record and changes what
tools expect. That size is to be the size of the entire allocated
space, not the size of an individual element or the number of them.
>
> > __data_size += __item_length;
> >
> > #undef __string
>
> BTW, if I revert commit ac01ce1410fc2 "tracing: Make
> ftrace_print_array_seq compute buf_len" it works again.
>
> I'm going to look into this some more, and maybe the answer is to go
> back and just pass in buffer length here. I can't see what was broken
> before that change.
I'm thinking the best thing to do is to revert that patch and make the
second argument of __print_array() the size and not the count.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists