linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@linutronix.de>
Cc: Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Clark Williams <williams@redhat.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Rikard Falkeborn <rikard.falkeborn@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tzvetomir Stoyanov <tstoyanov@vmware.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: [PATCH 6/7] tools lib traceevent: Fix missing equality check for strcmp
Date: Fri, 12 Apr 2019 11:22:49 -0300	[thread overview]
Message-ID: <20190412142250.20595-7-acme@kernel.org> (raw)
In-Reply-To: <20190412142250.20595-1-acme@kernel.org>

From: Rikard Falkeborn <rikard.falkeborn@gmail.com>

There was a missing comparison with 0 when checking if type is "s64" or
"u64". Therefore, the body of the if-statement was entered if "type" was
"u64" or not "s64", which made the first strcmp() redundant since if
type is "u64", it's not "s64".

If type is "s64", the body of the if-statement is not entered but since
the remainder of the function consists of if-statements which will not
be entered if type is "s64", we will just return "val", which is
correct, albeit at the cost of a few more calls to strcmp(), i.e., it
will behave just as if the if-statement was entered.

If type is neither "s64" or "u64", the body of the if-statement will be
entered incorrectly and "val" returned. This means that any type that is
checked after "s64" and "u64" is handled the same way as "s64" and
"u64", i.e., the limiting of "val" to fit in for example "s8" is never
reached.

This was introduced in the kernel tree when the sources were copied from
trace-cmd in commit f7d82350e597 ("tools/events: Add files to create
libtraceevent.a"), and in the trace-cmd repo in 1cdbae6035cei
("Implement typecasting in parser") when the function was introduced,
i.e., it has always behaved the wrong way.

Detected by cppcheck.

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Tzvetomir Stoyanov <tstoyanov@vmware.com>
Fixes: f7d82350e597 ("tools/events: Add files to create libtraceevent.a")
Link: http://lkml.kernel.org/r/20190409091529.2686-1-rikard.falkeborn@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/lib/traceevent/event-parse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
index 87494c7c619d..981c6ce2da2c 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -2233,7 +2233,7 @@ eval_type_str(unsigned long long val, const char *type, int pointer)
 		return val & 0xffffffff;
 
 	if (strcmp(type, "u64") == 0 ||
-	    strcmp(type, "s64"))
+	    strcmp(type, "s64") == 0)
 		return val;
 
 	if (strcmp(type, "s8") == 0)
-- 
2.20.1


  parent reply	other threads:[~2019-04-12 14:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 14:22 [GIT PULL 0/7] perf/urgent fixes Arnaldo Carvalho de Melo
2019-04-12 14:22 ` [PATCH 1/7] x86/perf/amd: Remove need to check "running" bit in NMI handler Arnaldo Carvalho de Melo
2019-04-12 14:22 ` [PATCH 2/7] x86/perf/amd: Fix build failure when CONFIG_HAVE_NMI_WATCHDOG is not set Arnaldo Carvalho de Melo
2019-04-12 14:22 ` [PATCH 3/7] perf header: Fix lock/unlock imbalances when processing BPF/BTF info Arnaldo Carvalho de Melo
2019-04-12 16:14   ` Song Liu
2019-04-12 14:22 ` [PATCH 4/7] perf scripts python: export-to-sqlite.py: Fix use of parent_id in calls_view Arnaldo Carvalho de Melo
2019-04-12 14:22 ` [PATCH 5/7] perf stat: Disable DIR_FORMAT feature for 'perf stat record' Arnaldo Carvalho de Melo
2019-04-12 14:22 ` Arnaldo Carvalho de Melo [this message]
2019-04-12 14:22 ` [PATCH 7/7] perf evsel: Use hweight64() instead of hweight_long(attr.sample_regs_user) Arnaldo Carvalho de Melo

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=20190412142250.20595-7-acme@kernel.org \
    --to=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=rikard.falkeborn@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tstoyanov@vmware.com \
    --cc=williams@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).