[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201002154417.320ad78b@gandalf.local.home>
Date: Fri, 2 Oct 2020 15:44:17 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Tom Zanussi <zanussi@...nel.org>
Cc: axelrasmussen@...gle.com, mhiramat@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] tracing: Change STR_VAR_MAX_LEN
On Thu, 1 Oct 2020 16:46:44 -0500
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.
>
> Tested-by: Axel Rasmussen <axelrasmussen@...gle.com>
> 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) */
Hmm, this requirement is now passed to MAX_FILTER_STR_VAL, but there's no
mention of it there. I guess we should have a
BUILD_BUG_ON(STR_VAR_LEN_MAX & (sizeof(u64) - 1));
in C code somewhere.
-- Steve
>
> struct synth_field {
> char *type;
Powered by blists - more mailing lists