[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJHvVchLJ4_Oha6bXa2k26JAy6hMVmOZpxfZRGvRPEUZahd5dw@mail.gmail.com>
Date: Wed, 30 Sep 2020 15:45:22 -0700
From: Axel Rasmussen <axelrasmussen@...gle.com>
To: Tom Zanussi <zanussi@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] tracing: Change STR_VAR_MAX_LEN
I still get the same WARN_ON behavior when trying to use bpftrace.
But, I spent some time today reading through that call path, and at
this point I'm convinced that it's the version of bpftrace I'm using
which is slightly broken, not the kernel in this case. (To be fair,
I'm trying to use some unreleased tip-of-tree version of it, with some
not-yet-merged patches, and some extra hacks on top of all that, so
it's not particularly surprising...)
In my experiments with just the synthetic event + histogram triggers,
this patchset works as expected for my use case.
So (for the whole series, not just this one patch):
Tested-by: Axel Rasmussen <axelrasmussen@...gle.com>
On Wed, Sep 30, 2020 at 11:41 AM Tom Zanussi <zanussi@...nel.org> wrote:
>
> 32 is too small for this value, and anyway it makes more sense to use
> MAX_FILTER_STR_VAL, as this is also the value used for variable-length
> __strings.
>
> Signed-off-by: Tom Zanussi <zanussi@...nel.org>
> ---
> kernel/trace/trace_synth.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace_synth.h b/kernel/trace/trace_synth.h
> index ac35c45207c4..5166705d1556 100644
> --- a/kernel/trace/trace_synth.h
> +++ b/kernel/trace/trace_synth.h
> @@ -7,7 +7,7 @@
> #define SYNTH_SYSTEM "synthetic"
> #define SYNTH_FIELDS_MAX 32
>
> -#define STR_VAR_LEN_MAX 32 /* must be multiple of sizeof(u64) */
> +#define STR_VAR_LEN_MAX MAX_FILTER_STR_VAL /* must be multiple of sizeof(u64) */
>
> struct synth_field {
> char *type;
> --
> 2.17.1
>
Powered by blists - more mailing lists