From: Steven Rostedt <rostedt@goodmis.org>
To: Tom Zanussi <zanussi@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
ionut_n2001@yahoo.com
Subject: Re: [PATCH] tracing: Check for NULL field_name in __synth_event_add_val()
Date: Sun, 19 Feb 2023 20:56:08 -0500 [thread overview]
Message-ID: <20230219205608.4664c310@rorschach.local.home> (raw)
In-Reply-To: <06c77bca76cd5679c8cd459480621b7db21f3a7b.camel@kernel.org>
On Sun, 19 Feb 2023 15:46:24 -0600
Tom Zanussi <zanussi@kernel.org> wrote:
> No, because this code just above it makes sure you can't mix add_name
> with add_next. Once add_name is set it will return -EINVAL if
> field_name is ever null after that, and add_name will never be changed
> once set:
>
> /* can't mix add_next_synth_val() with add_synth_val() */
> if (field_name) {
> if (trace_state->add_next) {
> ret = -EINVAL;
> goto out;
> }
> trace_state->add_name = true;
> } else {
> if (trace_state->add_name) {
> ret = -EINVAL;
> goto out;
> }
> trace_state->add_next = true;
> }
>
>
> > kernel/trace/trace_events_synth.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/kernel/trace/trace_events_synth.c
> > b/kernel/trace/trace_events_synth.c
> > index 70bddb25d9c0..fa28c1da06d2 100644
> > --- a/kernel/trace/trace_events_synth.c
> > +++ b/kernel/trace/trace_events_synth.c
> > @@ -1982,6 +1982,10 @@ static int __synth_event_add_val(const char
> > *field_name, u64 val,
> >
> > event = trace_state->event;
> > if (trace_state->add_name) {
> > + if (!field_name) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
>
> So if add_name is set here, it must also mean that field_name can't be
> null, because of the above.
>
> > for (i = 0; i < event->n_fields; i++) {
> > field = event->fields[i];
> > if (strcmp(field->name, field_name) == 0)
>
> And if field_name can't be null, then I don't see how this strcmp could
> fail due to a null field_name.
>
> So I don't see the need for this patch. The bugzilla shows a compiler
> warning when using -Wnonnull - could this just be a spurious gcc
> warning?
Thanks, I should have caught that (I was even looking for that logic,
but still missed it). That's what I get for writing patches while jet-lagged :-p
-- Steve
prev parent reply other threads:[~2023-02-20 1:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 15:59 [PATCH] tracing: Check for NULL field_name in __synth_event_add_val() Steven Rostedt
2023-02-19 21:46 ` Tom Zanussi
2023-02-20 1:56 ` Steven Rostedt [this message]
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=20230219205608.4664c310@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=ionut_n2001@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=zanussi@kernel.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.