1. 30 6月, 2017 8 次提交
  2. 21 6月, 2017 3 次提交
  3. 26 4月, 2017 1 次提交
  4. 20 4月, 2017 1 次提交
  5. 27 1月, 2017 1 次提交
    • A
      perf tools: Propagate perf_config() errors · ecc4c561
      Arnaldo Carvalho de Melo 提交于
      Previously these were being ignored, sometimes silently.
      
      Stop doing that, emitting debug messages and handling the errors.
      
      Testing it:
      
        $ cat ~/.perfconfig
        cat: /home/acme/.perfconfig: No such file or directory
        $ perf stat -e cycles usleep 1
      
         Performance counter stats for 'usleep 1':
      
                 938,996      cycles:u
      
             0.003813731 seconds time elapsed
      
        $ perf top --stdio
        Error:
        You may not have permission to collect system-wide stats.
      
        Consider tweaking /proc/sys/kernel/perf_event_paranoid,
        <SNIP>
        [ perf record: Captured and wrote 0.019 MB perf.data (7 samples) ]
        [acme@jouet linux]$ perf report --stdio
        # To display the perf.data header info, please use --header/--header-only options.
        # Overhead  Command  Shared Object      Symbol
        # ........  .......  .................  .........................
          71.77%  usleep   libc-2.24.so       [.] _dl_addr
          27.07%  usleep   ld-2.24.so         [.] _dl_next_ld_env_entry
           1.13%  usleep   [kernel.kallsyms]  [k] page_fault
        $
        $ touch ~/.perfconfig
        $ ls -la ~/.perfconfig
        -rw-rw-r--. 1 acme acme 0 Jan 27 12:14 /home/acme/.perfconfig
        $
        $ perf stat -e instructions usleep 1
      
         Performance counter stats for 'usleep 1':
      
                 244,610      instructions:u
      
             0.000805383 seconds time elapsed
      
        $
        [root@jouet ~]# chown acme.acme ~/.perfconfig
        [root@jouet ~]# perf stat -e cycles usleep 1
          Warning: File /root/.perfconfig not owned by current user or root, ignoring it.
      
         Performance counter stats for 'usleep 1':
      
                 937,615      cycles
      
             0.000836931 seconds time elapsed
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-j2rq96so6xdqlr8p8rd6a3jx@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ecc4c561
  6. 24 10月, 2016 2 次提交
  7. 29 9月, 2016 6 次提交
  8. 05 9月, 2016 2 次提交
  9. 24 6月, 2016 1 次提交
  10. 23 6月, 2016 2 次提交
  11. 18 4月, 2016 1 次提交
    • A
      perf intel-pt: Fix segfault tracing transactions · 1342e0b7
      Adrian Hunter 提交于
      Tracing a workload that uses transactions gave a seg fault as follows:
      
        perf record -e intel_pt// workload
        perf report
        Program received signal SIGSEGV, Segmentation fault.
        0x000000000054b58c in intel_pt_reset_last_branch_rb (ptq=0x1a36110)
        	at util/intel-pt.c:929
        929 ptq->last_branch_rb->nr = 0;
        (gdb) p ptq->last_branch_rb
        $1 = (struct branch_stack *) 0x0
        (gdb) up
        1148 intel_pt_reset_last_branch_rb(ptq);
        (gdb) l
        1143 if (ret)
        1144 pr_err("Intel Processor Trace: failed to deliver transaction event
        1145 ret);
        1146
        1147 if (pt->synth_opts.callchain)
        1148 intel_pt_reset_last_branch_rb(ptq);
        1149
        1150 return ret;
        1151 }
        1152
        (gdb) p pt->synth_opts.callchain
        $2 = true
        (gdb)
        (gdb) bt
         #0 0x000000000054b58c in intel_pt_reset_last_branch_rb (ptq=0x1a36110)
         #1 0x000000000054c1e0 in intel_pt_synth_transaction_sample (ptq=0x1a36110)
         #2 0x000000000054c5b2 in intel_pt_sample (ptq=0x1a36110)
      
      Caused by checking the 'callchain' flag when it should have been the
      'last_branch' flag.  Fix that.
      Reported-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: stable@vger.kernel.org # v4.4+
      Fixes: f14445ee ("perf intel-pt: Support generating branch stack")
      Link: http://lkml.kernel.org/r/1460977068-11566-1-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1342e0b7
  12. 30 3月, 2016 2 次提交
  13. 02 2月, 2016 1 次提交
    • A
      perf tools: Fix thread lifetime related segfaut in intel_pt · 3a4acda1
      Adrian Hunter 提交于
      intel_pt_process_auxtrace_info() creates a pt->unknown_thread thread
      that eventually needs to be freed by the last thread__put() on it, when
      its refcount hits zero, which may happen in
      intel_pt_process_auxtrace_info() error handling path and triggers the
      following segfault, which would happen as well at intel_pt_free, when
      tools using this intel_pt codebase frees up resources:
      
        # perf record -I -e intel_pt/tsc=1,noretcomp=1/u /bin/ls
        0  a  anaconda-ks.cfg  bin   perf.data	perf.data.old  perf-f23-bringup.todo
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.217 MB perf.data ]
        #
        # perf script -F event,comm,pid,tid,time,addr,ip,sym,dso,iregs
        Samples for 'instructions:u' event do not have IREGS attribute set. Cannot print 'iregs' field.
        intel_pt_synth_events: failed to synthesize 'instructions' event type
        Segmentation fault (core dumped)
        #
      
      The problem is: there's a union in 'struct thread' combines a list_head
      and a rb_node. The standard life cycle of a thread is: init rb_node in
      the constructor, insert it into machine->threads rbtree using rb_node,
      move it to machine->dead_threads using list_head, clean in the last
      thread__put: list_del_init(&thread->node).
      
      In the above command, it clean a thread before adding it into list,
      causes the above segfault.
      
      Since pt->unknown_thread will never live in an rbtree, initialize its
      list node so that when list_del_init() is done on it we don't segfault.
      
      After this patch:
      
        # perf script -F event,comm,pid,tid,time,addr,ip,sym,dso,iregs
        Samples for 'instructions:u' event do not have IREGS attribute set. Cannot print 'iregs' field.
        intel_pt_synth_events: failed to synthesize 'instructions' event type
        0x248 [0x88]: failed to process type: 70
        #
      Reported-by: NTong Zhang <ztong@vt.edu>
      Reported-by: NWang Nan <wangnan0@huawei.com>
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Link: http://lkml.kernel.org/r/1454296865-19749-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3a4acda1
  14. 14 12月, 2015 1 次提交
  15. 01 10月, 2015 1 次提交
  16. 29 9月, 2015 4 次提交
  17. 04 9月, 2015 1 次提交
  18. 03 9月, 2015 1 次提交
    • A
      perf tools: Fix use of wrong event when processing exit events · 53ff6bc3
      Adrian Hunter 提交于
      In a couple of cases the 'comm' member of 'union event' has been used
      instead of the correct member ('fork') when processing exit events.
      
      In the cases where it has been used incorrectly, only the 'pid' and
      'tid' are affected.  The 'pid' value would be correct anyway because it
      is in the same position in 'comm' and 'fork' events, but the 'tid' would
      have been incorrectly assigned from 'ppid'.
      
      However, for exit events, the kernel puts the current task in the 'ppid'
      and 'ttid' which is the same as the exiting task.  That is 'ppid' ==
      'pid' and if the task is not multi-threaded, 'pid' == 'tid' i.e. the
      data goes wrong only when tracing multi-threaded programs.
      
      It is hard to find an example of how this would produce an error in
      practice.  There are 3 occurences of the fix:
      
      1. perf script is only affected if !sample_id_all which only happens on
        old kernels.
      
      2. intel_pt is only affected when decoding without timestamps
         and would probably still decode correctly - the exit event is
         only used to flush out data which anyway gets flushed at the
         end of the session
      
      3. intel_bts also uses the exit event to flush data which
         would probably not cause errors as it would get flushed at
         the end of the session instead
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/1439888825-27708-1-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      53ff6bc3
  19. 25 8月, 2015 1 次提交