linux-stable.git/tools/lib, branch v3.16.67

tools/lib/lockdep: Rename "trywlock" into "trywrlock"

2019-04-04T15:13:48+00:00

commit 7f3c7952d111ac93573fb86f4d5aeff527a07fcc upstream.

This patch avoids that the following compiler warning is reported while
compiling the lockdep unit tests:

include/liblockdep/rwlock.h: In function 'liblockdep_pthread_rwlock_trywlock':
include/liblockdep/rwlock.h:66:9: warning: implicit declaration of function 'pthread_rwlock_trywlock'; did you mean 'pthread_rwlock_trywrlock'? [-Wimplicit-function-declaration]
  return pthread_rwlock_trywlock(&lock->rwlock) == 0 ? 1 : 0;
         ^~~~~~~~~~~~~~~~~~~~~~~
         pthread_rwlock_trywrlock

Signed-off-by: Bart Van Assche 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Johannes Berg 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sasha Levin 
Cc: Sasha Levin 
Cc: Thomas Gleixner 
Cc: Waiman Long 
Cc: johannes.berg@intel.com
Cc: tj@kernel.org
Fixes: 5a52c9b480e0 ("liblockdep: Add public headers for pthread_rwlock_t implementation")
Link: https://lkml.kernel.org/r/20181207011148.251812-6-bvanassche@acm.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings

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

2017-10-12T14:27:44+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

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

2016-06-15T20:29:32+00:00

commit 106b816cb46ebd87408b4ed99a2e16203114daa6 upstream.

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 
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 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

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

2016-02-02T17:29:13+00:00

commit 32abc2ede536aae52978d6c0a8944eb1df14f460 upstream.

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 
Link: http://lkml.kernel.org/r/20151116172516.4b79b109@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Luis Henriques

tools lib traceevent: Fix string handling in heterogeneous arch environments

2015-10-19T13:31:37+00:00

commit c2e4b24ff848bb180f9b9cd873a38327cd219ad2 upstream.

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 
Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

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

2015-05-05T10:09:31+00:00

commit c5e691928bf166ac03430e957038b60adba3cf6c upstream.

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 
Link: http://lkml.kernel.org/r/20150324135923.461431960@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Luis Henriques

Merge branch 'liblockdep-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux into locking/urgent

2014-07-16T12:57:27+00:00

Pull liblockdep fixes from Sasha Levin.

Signed-off-by: Ingo Molnar

tools/liblockdep: Account for bitfield changes in lockdeps lock_acquire

2014-07-07T16:20:16+00:00

Commit fb9edbe984 shortened held_lock->check from a 2-bit field
to a 1-bit field.

Make liblockdep compatible with the new definition by passing check=1
to lock_acquire() calls, rather than the old value check=2 (which
inadvertently disabled checks by overflowing to 0).

Without this fix, several of the test cases in liblockdep run_tests.sh
were failing.

Signed-off-by: S. Lockwood-Childs 
Signed-off-by: Sasha Levin

tools/liblockdep: Remove debug print left over from development

2014-07-07T16:14:27+00:00

Remove a debug print in init_preload() which was left over from
development and isn't usefull at all currently. It was also causing
false positive test results.

Reported-by: S. Lockwood-Childs 
Signed-off-by: Sasha Levin

tools/liblockdep: Fix comparison of a boolean value with a value of 2

2014-07-07T16:02:21+00:00

Comparison of a boolean value (!__init_state) with a value of 2 (done)
as currently happens in the code is unlikely to succeed and causes
repeated initialization of the pthread function pointers.

Instead, remove boolean comparison so that we would initialize said
function pointers only once.

Ref: https://bugzilla.kernel.org/show_bug.cgi?id=76741
Cc: Jean Delvare 
Reported-by: David Binderman 
Signed-off-by: Dianfang Zhang 
Signed-off-by: Sasha Levin