summaryrefslogtreecommitdiffstats
path: root/tools/usb
diff options
context:
space:
mode:
authorArnaldo Carvalho de Melo <acme@redhat.com>2015-07-13 08:26:35 -0300
committerLuis Henriques <luis.henriques@canonical.com>2015-08-11 09:57:26 +0100
commit6bf9964d1b716ed37a5cb97c47d808e18683fb9c (patch)
treef6a1ac54af10310b2d0165a45bb9395adfaa7fdc /tools/usb
parent8c7166f68bd7cf591932b7c1e92d3123c27926b0 (diff)
downloadlinux-stable-6bf9964d1b716ed37a5cb97c47d808e18683fb9c.tar.gz
linux-stable-6bf9964d1b716ed37a5cb97c47d808e18683fb9c.tar.bz2
linux-stable-6bf9964d1b716ed37a5cb97c47d808e18683fb9c.zip
perf hists browser: Take the --comm, --dsos, etc filters into account
commit 9c0fa8dd3d58de8b688fda758eea1719949c7f0a upstream. At some point: commit 2c86c7ca7606 Author: Namhyung Kim <namhyung@kernel.org> Date: Mon Mar 17 18:18:54 2014 -0300 perf report: Merge al->filtered with hist_entry->filtered We stopped dropping samples for things filtered via the --comms, --dsos, --symbols, etc, i.e. things marked as filtered in the symbol resolution routines (thread__find_addr_map(), perf_event__preprocess_sample(), etc). But then, in: commit 268397cb2a47 Author: Namhyung Kim <namhyung@kernel.org> Date: Tue Apr 22 14:49:31 2014 +0900 perf top/tui: Update nr_entries properly after a filter is applied We don't take into account entries that were filtered in perf_event__preprocess_sample() and friends, which leads to inconsistency in the browser seek routines, that expects the number of hist_entry->filtered entries to match what it thinks is the number of unfiltered, browsable entries. So, for instance, when we do: perf top --symbols ___non_existent_symbol___ the hist_browser__nr_entries() routine thinks there are no filters in place, uses the hists->nr_entries but all entries are filtered, leading to a segfault. Tested with: perf top --symbols malloc,free --percentage=relative Freezing, by pressing 'f', at any time and doing the math on the percentages ends up with 100%, ditto for: perf top --dsos libpthread-2.20.so,libxul.so --percentage=relative Both were segfaulting, all fixed now. More work needed to do away with checking if filters are in place, we should just use the nr_non_filtered_samples counter, no need to conditionally use it or hists.nr_filter, as what the browser does is just show unfiltered stuff. An audit of how it is being accounted is needed, this is the minimal fix. Reported-by: Michael Petlan <mpetlan@redhat.com> Fixes: 268397cb2a47 ("perf top/tui: Update nr_entries properly after a filter is applied") Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-6w01d5q97qk0d64kuojme5in@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Diffstat (limited to 'tools/usb')
0 files changed, 0 insertions, 0 deletions