1. 06 Aug, 2015 27 commits
  2. 05 Aug, 2015 11 commits
  3. 04 Aug, 2015 2 commits
    • Arnaldo Carvalho de Melo's avatar
      perf script: No tracepoints? Don't call libtraceevent. · 9ee67421
      Arnaldo Carvalho de Melo authored
      The libtraceevent handler (session->tevent) is only initialized when
      there are tracepoints in a perf.data event list, so do not call
      pevent_set_function_resolve() in those cases, fixing a segfault.
      Reported-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarJiri Olsa <jolsa@kernel.org>
      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: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-xyynkucl5p4bcs13zi4i4b1f@git.kernel.org
      Report-link: http://lkml.kernel.org/r/20150803174113.GA20282@krava.redhat.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      9ee67421
    • Peter Zijlstra's avatar
      perf/x86/intel/pebs: Robustify PEBS buffer drain · 75f80859
      Peter Zijlstra authored
      Vince Weaver and Stephane Eranian reported warnings in the PEBS
      code when running the perf fuzzer. Stephane wrote:
      
        > I can reproduce the problem on my HSW running the fuzzer.
        >
        > I can see why this could be happening if you are mixing PEBS and non PEBS events
        > in the bottom 4 counters. I suspect:
        >         for (bit = 0; bit < x86_pmu.max_pebs_events; bit++) {
        >                 if ((counts[bit] == 0) && (error[bit] == 0))
        >                         continue;
        >
        > This test is not correct when you have non-PEBS events mixed with
        > PEBS events and they overflow at the same time. They will have
        > counts[i] != 0 but error[i] == 0, and thus you fall thru the loop
        > and hit the assert. Or it is something along those lines.
      
      The only way I can make this work is if ->status only has !PEBS events
      set, because if it has both set we'll take that slow path which masks
      out the !PEBS bits.
      
      After masking there are 3 options:
      
       - there is one bit set, and its @bit, we increment counts[bit].
      
       - there are multiple bits set, we increment error[] for each set bit,
         we do not increment counts[].
      
       - there are no bits set, we do nothing.
      
      The intent was to never increment counts[] for !PEBS events.
      
      Now if we start out with only a single !PEBS event set, we'll pass the
      test and increment counts[] for a !PEBS and hit the warn.
      Reported-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Reported-by: default avatarStephane Eranian <eranian@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kan.liang@intel.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      75f80859