The only caller to this function (__print_array) was getting it wrong by
passing the array length instead of buffer length. As the element size
was already being passed for other reasons it seems reasonable to push
the calculation of buffer length into the function.
Signed-off-by: Alex Bennée <[email protected]>
---
v2:
- more explicit commit message
- rename len -> count to reduce ambiguity
---
include/linux/ftrace_event.h | 2 +-
kernel/trace/trace_output.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index c674ee8..33a66e6 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -45,7 +45,7 @@ const char *ftrace_print_hex_seq(struct trace_seq *p,
const unsigned char *buf, int len);
const char *ftrace_print_array_seq(struct trace_seq *p,
- const void *buf, int buf_len,
+ const void *buf, int count,
size_t el_size);
struct trace_iterator;
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 692bf71..25a086b 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -178,12 +178,13 @@ ftrace_print_hex_seq(struct trace_seq *p, const unsigned char *buf, int buf_len)
EXPORT_SYMBOL(ftrace_print_hex_seq);
const char *
-ftrace_print_array_seq(struct trace_seq *p, const void *buf, int buf_len,
+ftrace_print_array_seq(struct trace_seq *p, const void *buf, int count,
size_t el_size)
{
const char *ret = trace_seq_buffer_ptr(p);
const char *prefix = "";
void *ptr = (void *)buf;
+ size_t buf_len = count * el_size;
trace_seq_putc(p, '{');
--
2.3.5
On Wed, 29 Apr 2015 16:18:46 +0100
Alex Bennée <[email protected]> wrote:
> The only caller to this function (__print_array) was getting it wrong by
> passing the array length instead of buffer length. As the element size
> was already being passed for other reasons it seems reasonable to push
> the calculation of buffer length into the function.
>
> Signed-off-by: Alex Bennée <[email protected]>
Thanks, I'll add a stable tag to this too, and get it out soon.
-- Steve
>
> ---
> v2:
> - more explicit commit message
> - rename len -> count to reduce ambiguity
> ---
> include/linux/ftrace_event.h | 2 +-
> kernel/trace/trace_output.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
On Wed, Apr 29, 2015 at 04:18:46PM +0100, Alex Benn?e wrote:
> The only caller to this function (__print_array) was getting it wrong by
> passing the array length instead of buffer length. As the element size
> was already being passed for other reasons it seems reasonable to push
> the calculation of buffer length into the function.
>
> Signed-off-by: Alex Benn?e <[email protected]>
That looks better, thanks.
Reviewed-by: Dave Martin <[email protected]>
>
> ---
> v2:
> - more explicit commit message
> - rename len -> count to reduce ambiguity
> ---
> include/linux/ftrace_event.h | 2 +-
> kernel/trace/trace_output.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index c674ee8..33a66e6 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -45,7 +45,7 @@ const char *ftrace_print_hex_seq(struct trace_seq *p,
> const unsigned char *buf, int len);
>
> const char *ftrace_print_array_seq(struct trace_seq *p,
> - const void *buf, int buf_len,
> + const void *buf, int count,
> size_t el_size);
>
> struct trace_iterator;
> diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
> index 692bf71..25a086b 100644
> --- a/kernel/trace/trace_output.c
> +++ b/kernel/trace/trace_output.c
> @@ -178,12 +178,13 @@ ftrace_print_hex_seq(struct trace_seq *p, const unsigned char *buf, int buf_len)
> EXPORT_SYMBOL(ftrace_print_hex_seq);
>
> const char *
> -ftrace_print_array_seq(struct trace_seq *p, const void *buf, int buf_len,
> +ftrace_print_array_seq(struct trace_seq *p, const void *buf, int count,
> size_t el_size)
> {
> const char *ret = trace_seq_buffer_ptr(p);
> const char *prefix = "";
> void *ptr = (void *)buf;
> + size_t buf_len = count * el_size;
>
> trace_seq_putc(p, '{');
>
> --
> 2.3.5
>
Steven Rostedt <[email protected]> writes:
> On Wed, 29 Apr 2015 16:18:46 +0100
> Alex Bennée <[email protected]> wrote:
>
>> The only caller to this function (__print_array) was getting it wrong by
>> passing the array length instead of buffer length. As the element size
>> was already being passed for other reasons it seems reasonable to push
>> the calculation of buffer length into the function.
>>
>> Signed-off-by: Alex Bennée <[email protected]>
>
> Thanks, I'll add a stable tag to this too, and get it out soon.
I take it you'll pick up Dave's reviewed-by?
As for CC'ing stable I wouldn't worry too much as nothing in the kernel
uses __print_array yet (unless you count the example). But it is a
fairly trivial patch so if you as the maintainer is happy I'm happy ;-)
>
> -- Steve
>
>>
>> ---
>> v2:
>> - more explicit commit message
>> - rename len -> count to reduce ambiguity
>> ---
>> include/linux/ftrace_event.h | 2 +-
>> kernel/trace/trace_output.c | 3 ++-
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
--
Alex Bennée
On Wed, 29 Apr 2015 17:02:50 +0100
Alex Bennée <[email protected]> wrote:
>
> Steven Rostedt <[email protected]> writes:
>
> > On Wed, 29 Apr 2015 16:18:46 +0100
> > Alex Bennée <[email protected]> wrote:
> >
> >> The only caller to this function (__print_array) was getting it wrong by
> >> passing the array length instead of buffer length. As the element size
> >> was already being passed for other reasons it seems reasonable to push
> >> the calculation of buffer length into the function.
> >>
> >> Signed-off-by: Alex Bennée <[email protected]>
> >
> > Thanks, I'll add a stable tag to this too, and get it out soon.
>
> I take it you'll pick up Dave's reviewed-by?
Yep, I will.
>
> As for CC'ing stable I wouldn't worry too much as nothing in the kernel
> uses __print_array yet (unless you count the example). But it is a
> fairly trivial patch so if you as the maintainer is happy I'm happy ;-)
OK, if it's not used, then I'll just add it to this release.
Thanks,
-- Steve
On Wed, Apr 29, 2015 at 05:06:22PM +0100, Steven Rostedt wrote:
> On Wed, 29 Apr 2015 17:02:50 +0100
> Alex Bennée <[email protected]> wrote:
>
> >
> > Steven Rostedt <[email protected]> writes:
> >
> > > On Wed, 29 Apr 2015 16:18:46 +0100
> > > Alex Bennée <[email protected]> wrote:
> > >
> > >> The only caller to this function (__print_array) was getting it wrong by
> > >> passing the array length instead of buffer length. As the element size
> > >> was already being passed for other reasons it seems reasonable to push
> > >> the calculation of buffer length into the function.
> > >>
> > >> Signed-off-by: Alex Bennée <[email protected]>
> > >
> > > Thanks, I'll add a stable tag to this too, and get it out soon.
> >
> > I take it you'll pick up Dave's reviewed-by?
>
> Yep, I will.
>
> >
> > As for CC'ing stable I wouldn't worry too much as nothing in the kernel
> > uses __print_array yet (unless you count the example). But it is a
> > fairly trivial patch so if you as the maintainer is happy I'm happy ;-)
>
> OK, if it's not used, then I'll just add it to this release.
Our maintainer missed the merge window (sigh) so the patches that were
going to use this will have to wait until linux v4.2. So they will be
users in the future, but there's no need for this to go to stable.
Cheers,
Javi
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Wed, 29 Apr 2015 17:12:21 +0100
Javi Merino <[email protected]> wrote:
> Our maintainer missed the merge window (sigh) so the patches that were
> going to use this will have to wait until linux v4.2. So they will be
> users in the future, but there's no need for this to go to stable.
I'll still get this in for 4.1, as new code will depend on it.
-- Steve