linux-stable.git/tools/lib, branch linux-3.18.y

tools lib traceevent: Fix missing equality check for strcmp

2019-05-16T07:17:22+00:00

[ Upstream commit f32c2877bcb068a718bb70094cd59ccc29d4d082 ]

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 
Reviewed-by: Steven Rostedt (VMware) 
Cc: Tzvetomir Stoyanov 
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 
Signed-off-by: Sasha Levin

tools lib traceevent: Fix buffer overflow in arg_eval

2019-04-27T07:30:21+00:00

[ Upstream commit 7c5b019e3a638a5a290b0ec020f6ca83d2ec2aaa ]

Fix buffer overflow observed when running perf test.

The overflow is when trying to evaluate "1ULL << (64 - 1)" which is
resulting in -9223372036854775808 which overflows the 20 character
buffer.

If is possible this bug has been reported before but I still don't see
any fix checked in:

See: https://www.spinics.net/lists/linux-perf-users/msg07714.html

Reported-by: Michael Sartain 
Reported-by: Mathias Krause 
Signed-off-by: Tony Jones 
Acked-by: Steven Rostedt (VMware) 
Cc: Frederic Weisbecker 
Fixes: f7d82350e597 ("tools/events: Add files to create libtraceevent.a")
Link: http://lkml.kernel.org/r/20190228015532.8941-1-tonyj@suse.de
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

perf tools: Fix statfs.f_type data type mismatch build error with uclibc

2018-11-10T15:39:17+00:00

[ Upstream commit db1806edcfef007d9594435a331dcf7e7f1b8fac ]

ARC Linux uses the no legacy syscalls abi and corresponding uClibc headers
statfs defines f_type to be U32 which causes perf build breakage

http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common-generic/bits/statfs.h

  ----------->8---------------
    CC       fs/fs.o
  fs/fs.c: In function 'fs__valid_mount':
  fs/fs.c:82:24: error: comparison between signed and unsigned integer
  expressions [-Werror=sign-compare]
    else if (st_fs.f_type != magic)
                          ^
  cc1: all warnings being treated as errors
  ----------->8---------------

Signed-off-by: Alexey Brodkin 
Acked-by: Jiri Olsa 
Cc: Borislav Petkov 
Cc: Cody P Schafer 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Vineet Gupta 
Link: http://lkml.kernel.org/r/1420888254-17504-2-git-send-email-vgupta@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

tools lib traceevent: Fix get_field_str() for dynamic strings

2018-05-30T05:47:30+00:00

[ Upstream commit d777f8de99b05d399c0e4e51cdce016f26bd971b ]

If a field is a dynamic string, get_field_str() returned just the
offset/size value and not the string. Have it parse the offset/size
correctly to return the actual string. Otherwise filtering fails when
trying to filter fields that are dynamic strings.

Reported-by: Gopanapalli Pradeep 
Signed-off-by: Steven Rostedt 
Acked-by: Namhyung Kim 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/20180112004823.146333275@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth

2017-07-21T06:12:22+00:00

commit 98dcea0cfd04e083ac74137ceb9a632604740e2d upstream.

liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.

That should have resulted in a compiler error, but didn't because:

- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
  so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
  turns it into some nonsense involving a variable-length array

It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).

Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.

Signed-off-by: Ben Hutchings 
Signed-off-by: Sasha Levin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

tools lib traceevent: Do not reassign parg after collapse_tree()

2016-05-18T02:05:21+00:00

[ Upstream commit 106b816cb46ebd87408b4ed99a2e16203114daa6 ]

At the end of process_filter(), collapse_tree() was changed to update
the parg parameter, but the reassignment after the call wasn't removed.

What happens is that the "current_op" gets modified and freed and parg
is assigned to the new allocated argument. But after the call to
collapse_tree(), parg is assigned again to the just freed "current_op",
and this causes the tool to crash.

The current_op variable must also be assigned to NULL in case of error,
otherwise it will cause it to be free()ed twice.

Signed-off-by: Steven Rostedt 
Acked-by: Namhyung Kim 
Cc: stable@vger.kernel.org # 3.14+
Fixes: 42d6194d133c ("tools lib traceevent: Refactor process_filter()")
Link: http://lkml.kernel.org/r/20160511150936.678c18a1@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

tools lib traceevent: Free filter tokens in process_filter()

2016-05-18T02:05:14+00:00

[ Upstream commit e1644aae4589274223c1ab9072ddbda98dd97f6a ]

valgrind showed that the filter token wasn't being freed properly in
process_filter().

Signed-off-by: Steven Rostedt 
Cc: Andrew Morton 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/20150324135923.817723903@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

tools lib traceevent: Fix output of %llu for 64 bit values read on 32 bit machines

2016-02-02T18:53:25+00:00

[ Upstream commit 32abc2ede536aae52978d6c0a8944eb1df14f460 ]

When a long value is read on 32 bit machines for 64 bit output, the
parsing needs to change "%lu" into "%llu", as the value is read
natively.

Unfortunately, if "%llu" is already there, the code will add another "l"
to it and fail to parse it properly.

Signed-off-by: Steven Rostedt 
Acked-by: Namhyung Kim 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20151116172516.4b79b109@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

tools lib traceevent: Fix string handling in heterogeneous arch environments

2015-10-28T02:14:13+00:00

[ Upstream commit c2e4b24ff848bb180f9b9cd873a38327cd219ad2 ]

When a trace recorded on a 32-bit device is processed with a 64-bit
binary, the higher 32-bits of the address need to ignored.

The lack of this results in the output of the 64-bit pointer
value to the trace as the 32-bit address lookup fails in find_printk().

Before:

  burn-1778  [003]   548.600305: bputs:   0xc0046db2s: 2cec5c058d98c

After:

  burn-1778  [003]   548.600305: bputs:   0xc0046db2s: RT throttling activated

The problem occurs in PRINT_FIELD when the field is recognized as a
pointer to a string (of the type const char *)

Heterogeneous architectures cases below can arise and should be handled:

* Traces recorded using 32-bit addresses processed on a 64-bit machine
* Traces recorded using 64-bit addresses processed on a 32-bit machine

Reported-by: Juri Lelli 
Signed-off-by: Kapileshwar Singh 
Reviewed-by: Steven Rostedt 
Cc: David Ahern 
Cc: Javi Merino 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

tools lib traceevent kbuffer: Remove extra update to data pointer in PADDING

2015-05-17T23:12:09+00:00

[ Upstream commit c5e691928bf166ac03430e957038b60adba3cf6c ]

When a event PADDING is hit (a deleted event that is still in the ring
buffer), translate_data() sets the length of the padding and also updates
the data pointer which is passed back to the caller.

This is unneeded because the caller also updates the data pointer with
the passed back length. translate_data() should not update the pointer,
only set the length.

Signed-off-by: Steven Rostedt 
Cc: Andrew Morton 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: stable@vger.kernel.org # 3.12+
Link: http://lkml.kernel.org/r/20150324135923.461431960@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin