All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Zanussi <zanussi@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>,
	Pengpeng Hou <pengpeng@iscas.ac.cn>
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
	 linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] tracing/hist: rebuild full_name on each hist_field_name() call
Date: Wed, 08 Apr 2026 10:58:06 -0500	[thread overview]
Message-ID: <f59d594ff21658db45c58a094edeab0f92ae8345.camel@kernel.org> (raw)
In-Reply-To: <20260407210502.102e5d37@gandalf.local.home>

Hi Steve,

On Tue, 2026-04-07 at 21:05 -0400, Steven Rostedt wrote:
> 
> Tom,
> 
> On Wed,  1 Apr 2026 19:22:23 +0800
> Pengpeng Hou <pengpeng@iscas.ac.cn> wrote:
> 
> > hist_field_name() uses a static MAX_FILTER_STR_VAL buffer for fully
> > qualified variable-reference names, but it currently appends into that
> > buffer with strcat() without rebuilding it first. As a result, repeated
> > calls append a new "system.event.field" name onto the previous one,
> > which can eventually run past the end of full_name.
> > 
> > Build the name with snprintf() on each call and return NULL if the fully
> > qualified name does not fit in MAX_FILTER_STR_VAL.
> > 
> > Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers")
> > Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> > ---
> > Changes since v1: https://lore.kernel.org/all/20260329030950.32503-1-pengpeng@iscas.ac.cn/
> > 
> > - rebuild full_name on each call instead of falling back to field->name
> > - return NULL on overflow as suggested
> > - split out the snprintf() length check instead of using an inline if
> > 
> >  kernel/trace/trace_events_hist.c | 12 +++++++-----
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
> > index 73ea180cad55..f9c8a4f078ea 100644
> > --- a/kernel/trace/trace_events_hist.c
> > +++ b/kernel/trace/trace_events_hist.c
> > @@ -1361,12 +1361,14 @@ static const char *hist_field_name(struct hist_field *field,
> >  		 field->flags & HIST_FIELD_FL_VAR_REF) {
> >  		if (field->system) {
> >  			static char full_name[MAX_FILTER_STR_VAL];
> > +			int len;
> > +
> > +			len = snprintf(full_name, sizeof(full_name), "%s.%s.%s",
> > +				       field->system, field->event_name,
> > +				       field->name);
> > +			if (len >= sizeof(full_name))
> > +				return NULL;
> >  
> > -			strcat(full_name, field->system);
> > -			strcat(full_name, ".");
> > -			strcat(full_name, field->event_name);
> > -			strcat(full_name, ".");
> > -			strcat(full_name, field->name);
> >  			field_name = full_name;
> 
> I wanted to test this but I can't find anything that triggers this path.
> How does a field here get its ->system set?
> 

->system is set when using fully-qualified variable names. For
instance:

echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> sys/kernel/debug/tracing/events/sched/sched_waking/trigger
echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
echo 'hist:keys=next_pid:lat0=common_timestamp.usecs-sched.sched_waking.$ts0:lat1=common_timestamp.usecs-sched.sched_wakeup.$ts0' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
echo 'hist:keys=next_pid:vals=$lat0,$lat1' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger

Here, the sched_switch trigger would error out if the unqualified $ts0
variables were used instead of the fully-qualified ones because there's
no way to distinguish which $ts0 was meant.

Tom



> If there's no way to hit this path, I much rather remove it than "fix" it.
> 
> -- Steve
> 
> 
> >  		} else
> >  			field_name = field->name;
> 


  reply	other threads:[~2026-04-08 15:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-29  3:09 [PATCH 1/2] tracing/hist: bound full field-name construction Pengpeng Hou
2026-03-29 18:39 ` Steven Rostedt
2026-03-30  2:46 ` [PATCH v2 1/2] tracing/hist: rebuild full_name on each hist_field_name() call Pengpeng Hou
2026-03-30 14:22   ` Steven Rostedt
2026-04-01 11:22 ` Pengpeng Hou
2026-04-08  1:05   ` Steven Rostedt
2026-04-08 15:58     ` Tom Zanussi [this message]
2026-04-08 16:25       ` Steven Rostedt
2026-04-08 17:18         ` Tom Zanussi
2026-04-08  2:15   ` Pengpeng Hou
2026-04-08  2:14     ` Steven Rostedt
2026-04-13 22:38   ` Tom Zanussi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f59d594ff21658db45c58a094edeab0f92ae8345.camel@kernel.org \
    --to=zanussi@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=pengpeng@iscas.ac.cn \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.