1. 29 9月, 2015 16 次提交
  2. 25 9月, 2015 3 次提交
  3. 23 9月, 2015 9 次提交
  4. 22 9月, 2015 8 次提交
    • K
      tools lib traceevent: Fix string handling in heterogeneous arch environments · c2e4b24f
      Kapileshwar Singh 提交于
      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: NJuri Lelli <juri.lelli@arm.com>
      Signed-off-by: NKapileshwar Singh <kapileshwar.singh@arm.com>
      Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Javi Merino <javi.merino@arm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c2e4b24f
    • J
      perf tools: Add include/err.h into MANIFEST · 96d8bf75
      Jiri Olsa 提交于
      Otherwise the tarpkg is incomplete (tarpkg tests fails).
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Fixes: 01ca9fd4 ("tools: Add err.h with ERR_PTR PTR_ERR interface")
      Link: http://lkml.kernel.org/r/1442846143-8556-1-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      96d8bf75
    • A
      tools lib bpf: Use FEATURE_USER to allow building in the same dir as perf · 65f041be
      Arnaldo Carvalho de Melo 提交于
      When building tools/lib/bpf as part of the tools/perf/ build process,
      which will happend when we introduce a patch wiring that up, we end up
      stomping on the feature detection caching mechanism, that uses a file in
      the output directory (O=) that is shared by libbpf and perf to check if
      something changed from one build to another that requires redoing the
      feature detection process.
      
      By using the recently introduced FEATURE_USER tools/build/ knob, we can
      avoid that:
      
      Before, every make invokation would run the feature detection:
      
        $ make O=/tmp/build/perf -C tools/perf
        make: Entering directory '/home/git/linux/tools/perf'
        Auto-detecting system features:
        ...                         dwarf: [ on  ]
        ...                         glibc: [ on  ]
        <SNIP>
        ...                     get_cpuid: [ on  ]
        ...                           bpf: [ on  ]
      
          GEN      perf-archive
          GEN      perf-with-kcore
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...                           bpf: [ on  ]
        <SNIP>
      
      After:
      
        $ make O=/tmp/build/perf -C tools/perf
        make: Entering directory '/home/git/linux/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
        make: Leaving directory '/home/git/linux/tools/perf'
        $
      
      Because we now have two different feature detection state files:
      
        $ ls -la /tmp/build/perf/FEATURE-DUMP*
        -rw-rw-r--. 1 acme acme 338 Sep 21 17:25 /tmp/build/perf/FEATURE-DUMP
        -rw-rw-r--. 1 acme acme  33 Sep 21 17:25 /tmp/build/perf/FEATURE-DUMP.libbpf
        $
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexei Starovoitov <ast@plumgrid.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>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: pi3orama@163.com
      Fixes: 1b76c13e ("bpf tools: Introduce 'bpf' library and add bpf feature check")
      Link: http://lkml.kernel.org/n/tip-s6ev9wfqy7pvvs58emys2g90@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      65f041be
    • A
      tools build: Allow setting the feature detection user · 13e96db6
      Arnaldo Carvalho de Melo 提交于
      We will use the tools/build/ autodetection in the eBPF patchkit
      and it is currently sharing the output directory with perf, that
      also uses the feature detection logic.
      
      As we keep state in the output directory, so that we can avoid running
      all the tests again, we need to have different filenames for the files
      used in this state, allow doing that via the FEATURE_USER variable, to
      be set alongside the existing FEATURE_{TEST,DISPLAY} variables.
      
      v2: Fix comment describing the FEATURE_DUMP filename to make sure where
          it is created, precisely at $(OUTPUT)FEATURE-DUMP$(FEATURE_USER).
          Pointed out by Jiri.
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      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>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/n/tip-fdbev0vrn3x6idqc3ajbnvcb@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      13e96db6
    • A
      tools lib bpf: Fix up FEATURE_{TESTS,DISPLAY} usage · 20517cd9
      Arnaldo Carvalho de Melo 提交于
      When libbpf was introduced it wrongly asked for the "libelf" and "bpf"
      feature tests to be performed (via FEATURE_TESTS), while asking that
      "libbpf", "libelf-mmap", "libelf-getphdrnum" and "bpf" to have the
      result of its respective tests to be displayed (via FEATURE_DISPLAY).
      
      Due to another recently bug fixed in the tools/build/ infrastructure
      ("tools build: Fixup feature detection display function name") the
      results for the entries in the FEATURE_DISPLAY, for this case, were
      appearing as all succeeding, when two of them (the ones only on the
      DISPLAY) were not even being performed.
      
      Before:
      
        $ make -C tools/lib/bpf/
        make: Entering directory '/home/git/linux/tools/lib/bpf'
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...             libelf-getphdrnum: [ OFF ]
        ...                   libelf-mmap: [ OFF ]
        ...                           bpf: [ on  ]
        <SNIP>
      
      After, with FEATURE_TESTS == FEATURE_DISPLAY:
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...             libelf-getphdrnum: [ on  ]
        ...                   libelf-mmap: [ on  ]
        ...                           bpf: [ on  ]
        <SNIP>
      
      I just inverted, so that it tests the four features but displays just
      the libelf and mmap ones, to make it more compact. So it becomes:
      
        $ make -C tools/lib/bpf/
        make: Entering directory '/home/git/linux/tools/lib/bpf'
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...                           bpf: [ on  ]
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexei Starovoitov <ast@plumgrid.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>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: pi3orama@163.com
      Fixes: 1b76c13e ("bpf tools: Introduce 'bpf' library and add bpf feature check")
      Link: http://lkml.kernel.org/n/tip-y4bd59e6j9rzzojiyeqrg2jq@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      20517cd9
    • A
      tools build: Fixup feature detection display function name · 6076e2a4
      Arnaldo Carvalho de Melo 提交于
      Cut'n'paste mistake, it should eval the name of the function
      defined right next to it, in the next line, fix it.
      
      Before:
      
        $ make -C tools/lib/bpf/
        make: Entering directory '/home/git/linux/tools/lib/bpf'
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...             libelf-getphdrnum: [ on  ]
        ...                   libelf-mmap: [ on  ]
        ...                           bpf: [ on  ]
        <SNIP>
      
      After:
      
        $ make -C tools/lib/bpf/
        make: Entering directory '/home/git/linux/tools/lib/bpf'
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...             libelf-getphdrnum: [ OFF ]
        ...                   libelf-mmap: [ OFF ]
        ...                           bpf: [ on  ]
        <SNIP>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexei Starovoitov <ast@plumgrid.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>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: pi3orama@163.com
      Fixes: 58d4f00f ("perf build: Fix feature_check name clash")
      Link: http://lkml.kernel.org/n/tip-dzu1c4sruukgfq5d5b1c4r30@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6076e2a4
    • W
      perf tools: Don't assume that the parser returns non empty evsel list · 854f7363
      Wang Nan 提交于
      Don't blindly retrieve and use a last element in the lists returned by
      parse_events__scanner(), as it may have collected no entries, i.e.
      return an empty list.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1441523623-152703-2-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      854f7363
    • M
      perf probe: Fix a segfault when removing uprobe events · 0fb18553
      Masami Hiramatsu 提交于
      Fix a segfault bug and a small mistake in perf probe -d.
      
      Since the "ulist" in perf_del_probe_events is never initialized,
      strlist__add(ulist, *) always causes a segfault when removing
      uprobe events by perf probe -d.
      
      Also, the "str" local variable is never released if fail to
      allocate the "klist". This fixes it too.
      
      This has been introduced by the commit e607f142 ("perf probe:
      Print deleted events in cmd_probe()").
      Reported-by: NMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/20150916125241.4446.44805.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0fb18553
  5. 18 9月, 2015 4 次提交
    • M
      perf record: Avoid infinite loop at buildid processing with no samples · 381c02f6
      Mark Rutland 提交于
      If a session contains no events, we can get stuck in an infinite loop in
      __perf_session__process_events, with a non-zero file_size and data_offset, but
      a zero data_size.
      
      In this case, we can mmap the entirety of the file (consisting of the file and
      attribute headers), and fetch_mmaped_event will correctly refuse to read any
      (unmapped and non-existent) event headers. This causes
      __perf_session__process_events to unmap the file and retry with the exact same
      parameters, getting stuck in an infinite loop.
      
      This has been observed to result in an exit-time hang when counting
      rare/unschedulable events with perf record, and can be triggered artificially
      with the script below:
      
        ----
        #!/bin/sh
        printf "REPRO: launching perf\n";
        ./perf record -e software/config=9/ sleep 1 &
        PERF_PID=$!;
        sleep 0.002;
        kill -2 $PERF_PID;
        printf "REPRO: waiting for perf (%d) to exit...\n" "$PERF_PID";
        wait $PERF_PID;
        printf "REPRO: perf exited\n";
        ----
      
      To avoid this, have __perf_session__process_events bail out early when
      the file has no data (i.e. it has no events).
      
      Commiter note:
      
      I only managed to reproduce this when setting
      /proc/sys/kernel/kptr_restrict to '1' and changing the code to
      purposefully not process any samples and no synthesized samples, i.e.
      kptr_restrict prevents 'record' from synthesizing the kernel mmaps for
      vmlinux + modules and since it is a workload started from perf, we don't
      synthesize mmap/comm records for existing threads.
      
      Adrian Hunter managed to reproduce it in his environment tho.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Tested-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1442423929-12253-1-git-send-email-mark.rutland@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      381c02f6
    • P
      perf tools: Bool functions shouldn't return -1 · bf644563
      Peter Senna Tschudin 提交于
      Returning a negative value for a boolean function seem to have the
      undesired effect of returning true. Replace -1 by false in a
      bool-returning function.
      
      The diff of the .s file before and after the change (for x86_64):
      
        3907c3907
        < 	movl	$1, %ebx
        ---
        > 	xorl	%ebx, %ebx
      
      while if -1 is replaced by true, the diff is empty.
      
      This issue was found by the following Coccinelle semantic patch:
      
        <smpl>
        @@
        identifier f;
        constant C;
        typedef bool;
        @@
        bool f (...){
        <+...
        * return -C;
        ...+>
        }
        </smpl>
      Signed-off-by: NPeter Senna Tschudin <peter.senna@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Milos Vyletel <milos@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1442484533-19742-1-git-send-email-peter.senna@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bf644563
    • A
      tools build: Add test for presence of __get_cpuid() gcc builtin · b0063dbf
      Arnaldo Carvalho de Melo 提交于
      The auxtrace code needed by Intel PT uses the __get_cpuid() gcc builtin,
      that is not present in old systems, breaking the build.
      
      Add a test to check for that builtin and disable AUXTRACE in those
      systems.
      
        [acme@rhel5 linux]$  make NO_LIBPERL=1 -C tools/perf O=/tmp/build/perf install-bin
        make: Entering directory `/home/acme/git/linux/tools/perf'
          BUILD:   Doing 'make -j2' parallel build
      
        Auto-detecting system features:
        <SNIP>
        ...                          lzma: [ on  ]
        ...                     get_cpuid: [ OFF ]
        <SNIP>
        config/Makefile:630: Your gcc lacks the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please install a newer gcc
          MKDIR    /tmp/build/perf/util/
        <SNIP>
      
      This fixes the build on old systems such as RHEL/CentOS 5.11.
      
      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@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Victor Kamensky <victor.kamensky@linaro.org>
      Cc: Vinson Lee <vlee@twopensource.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-d4puslul0jltoodzpx9r4sje@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b0063dbf
    • A
      tools build: Add test for presence of numa_num_possible_cpus() in libnuma · f8ac8606
      Arnaldo Carvalho de Melo 提交于
      The existing numa test checks only if numa.h and numa_available() are
      present, but that can be satisfied with an old libnuma that is not
      enough for the 'perf bench numa' entry, so add a test to check for that:
      
        [acme@rhel5 linux]$  make NO_AUXTRACE=1 NO_LIBPERL=1 -C tools/perf O=/tmp/build/perf install-bin
        make: Entering directory `/home/acme/git/linux/tools/perf'
          BUILD:   Doing 'make -j2' parallel build
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...                       libnuma: [ on  ]
        ...        numa_num_possible_cpus: [ OFF ]
        ...                       libperl: [ on  ]
      
        <SNIP>
        config/Makefile:577: Old numa library found, disables 'perf bench numa mem' benchmark, please install numactl-devel/libnuma-devel/libnuma-dev >= 2.0.8
          INSTALL  binaries
        <SNIP>
      
      This fixes the build on old systems such as RHEL/CentOS 5.11.
      
      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@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Victor Kamensky <victor.kamensky@linaro.org>
      Cc: Vinson Lee <vlee@twopensource.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-zqriqkezppi2de2iyjin1tnc@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f8ac8606