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

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

tools lib fd array: Allow associating an integer cookie with each entry

2014-09-25T19:46:55+00:00

We will use this in perf's evlist class so that it can, at
fdarray__filter() time, to unmap the associated ring buffer.

We may need to have further info associated with each fdarray entry, in
that case we'll make that int array a 'union fdarray_priv' one and put a
pointer there so that users can stash whatever they want there. For now,
an int is enough tho.

v2: Add clarification to the per array entry priv area, as well as make
    it a union, which makes usage a bit longer, but if/when we make it
    use more space by allowing per entry pointers existing users source
    code will not have to be changed, just rebuilt.

Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Signed-off-by: Arnaldo Carvalho de Melo 

Link: http://lkml.kernel.org/n/tip-0p00bn83quck3fio3kcs9vca@git.kernel.org

tools lib api: Adopt fdarray class from perf's evlist

2014-09-25T19:46:55+00:00

The extensible file description array that grew in the perf_evlist class
can be useful for other tools, as it is not something that only evlists
need, so move it to tools/lib/api/fd to ease sharing it.

v2: Don't use {} like in:

 libapi_dirs:
	$(QUIET_MKDIR)mkdir -p $(OUTPUT){fs,fd}/

in Makefiles, as it will not work in some systems, as in ubuntu13.10.

v3: Add fd/*.[ch] to LIBAPIKFS_SOURCES (Fix from Jiri Olsa)

v4: Leave the fcntl(fd, O_NONBLOCK) in the evlist layer, remains to
    be checked if it is really needed there, but has no place in the
    fdarray class (Fix from Jiri Olsa)

v5: Remove evlist details from fdarray grow/filter tests. Improve it a
    bit doing more tests about expected internal state.

Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-kleuni3hckbc3s0lu6yb9x40@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

Merge tag 'v3.16-rc7' into perf/core, to merge in the latest fixes before applying new changes

2014-07-28T08:00:33+00:00

Signed-off-by: Ingo Molnar

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