Skip to content
  1. Sep 25, 2015
    • Arnaldo Carvalho de Melo's avatar
      perf probe: Use existing routine to look for a kernel module by dso->short_name · 266fa2b2
      Arnaldo Carvalho de Melo authored
      
      
      We have map_groups__find_by_name() to look at the list of modules that
      are in place for a given machine, so use it instead of traversing the
      machine dso list, which also includes DSOs for userspace.
      
      When merging the user and kernel DSO lists a bug was introduced where
      'perf probe' stopped being able to add probes to modules using its short
      name:
      
        # perf probe -m usbnet --add usbnet_start_xmit
        usbnet_start_xmit is out of .text, skip it.
          Error: Failed to add events.
        #
      
      With this fix it works again:
      
        # perf probe -m usbnet --add usbnet_start_xmit
        Added new event:
          probe:usbnet_start_xmit (on usbnet_start_xmit in usbnet)
      
        You can now use it in all perf tools, such as:
      
        	perf record -e probe:usbnet_start_xmit -aR sleep 1
        #
      
      Reported-by: default avatarWang Nan <wangnan0@huawei.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.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: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Fixes: 3d39ac53 ("perf machine: No need to have two DSOs lists")
      Link: http://lkml.kernel.org/r/20150924015008.GE1897@kernel.org
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      266fa2b2
  2. Sep 22, 2015
  3. Sep 18, 2015
    • Mark Rutland's avatar
      perf record: Avoid infinite loop at buildid processing with no samples · 381c02f6
      Mark Rutland authored
      
      
      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: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Tested-by: default avatarAdrian 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.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      381c02f6
  4. Sep 17, 2015
    • Peter Senna Tschudin's avatar
      perf tools: Bool functions shouldn't return -1 · bf644563
      Peter Senna Tschudin authored
      
      
      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: default avatarPeter 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.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      bf644563
    • Arnaldo Carvalho de Melo's avatar
      tools build: Add test for presence of __get_cpuid() gcc builtin · b0063dbf
      Arnaldo Carvalho de Melo authored
      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.org
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b0063dbf
    • Arnaldo Carvalho de Melo's avatar
      tools build: Add test for presence of numa_num_possible_cpus() in libnuma · f8ac8606
      Arnaldo Carvalho de Melo authored
      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.org
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      f8ac8606
    • Arnaldo Carvalho de Melo's avatar
      Revert "perf symbols: Fix mismatched declarations for elf_getphdrnum" · 179f36dd
      Arnaldo Carvalho de Melo authored
      
      
      This reverts commit f785f235.
      
      We have a test to check if elf_getphdrnum() is present, so, if it fails,
      we'll get:
      
        [acme@rhel5 linux]$ cat /tmp/build/perf/feature/test-libelf-getphdrnum.make.output
        cc1: warnings being treated as errors
        test-libelf-getphdrnum.c: In function ‘main’:
        test-libelf-getphdrnum.c:7: warning: implicit declaration of function ‘elf_getphdrnum’
        [acme@rhel5 linux]$
      
      And this block will not be compiled:
      
        #ifndef HAVE_ELF_GETPHDRNUM_SUPPORT
        static int elf_getphdrnum(Elf *elf, size_t *dst)
        ...
        #endif
      
      So, if elf_getphdrnum() is being defined somewhere, there is a problem
      with the test that is not detecting that function, go fix it.
      
      Reported-by: default avatarVinson Lee <vlee@twopensource.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: 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: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-qn459fal6acvcvm50i8zxx9k@git.kernel.org
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      179f36dd
  5. Sep 16, 2015
    • Stephane Eranian's avatar
      perf stat: Fix per-pkg event reporting bug · 02d8dabc
      Stephane Eranian authored
      
      
      Per-pkg events need to be captured once per processor socket. The code
      in check_per_pkg() ensures only one value per processor package is used.
      However there is a problem with this function in case the first CPU of
      the package does not measure anything for the per-pkg event, but other
      CPUs do.
      
      Consider the following:
      
        $ create cgroup FOO; echo $$ >FOO/tasks; taskset -c 1 noploop &
        $ perf stat -a -I 1000 -e intel_cqm/llc_occupancy/ -G FOO sleep 100
          1.00000 <not counted> Bytes intel_cqm/llc_occupancy/  FOO
      
      The reason for this is that CPU0 in the cgroup has nothing running on it.
      Yet check_per_plg() will mark socket0 as processed and no other event
      value will be considered for the socket.
      
      This patch fixes the problem by having check_per_pkg() only consider
      events which actually ran.
      
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1441286620-10117-1-git-send-email-eranian@google.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      02d8dabc
  6. Sep 15, 2015
  7. Sep 14, 2015
  8. Sep 13, 2015
    • Arnaldo Carvalho de Melo's avatar
      perf header: Fixup reading of HEADER_NRCPUS feature · caa47047
      Arnaldo Carvalho de Melo authored
      
      
      The original patch introducing this header wrote the number of CPUs available
      and online in one order and then swapped those values when reading, fix it.
      
      Before:
      
        # perf record usleep 1
        # perf report --header-only | grep 'nrcpus \(online\|avail\)'
        # nrcpus online : 4
        # nrcpus avail : 4
        # echo 0 > /sys/devices/system/cpu/cpu2/online
        # perf record usleep 1
        # perf report --header-only | grep 'nrcpus \(online\|avail\)'
        # nrcpus online : 4
        # nrcpus avail : 3
        # echo 0 > /sys/devices/system/cpu/cpu1/online
        # perf record usleep 1
        # perf report --header-only | grep 'nrcpus \(online\|avail\)'
        # nrcpus online : 4
        # nrcpus avail : 2
      
      After the fix, bringing back the CPUs online:
      
        # perf report --header-only | grep 'nrcpus \(online\|avail\)'
        # nrcpus online : 2
        # nrcpus avail : 4
        # echo 1 > /sys/devices/system/cpu/cpu2/online
        # perf record usleep 1
        # perf report --header-only | grep 'nrcpus \(online\|avail\)'
        # nrcpus online : 3
        # nrcpus avail : 4
        # echo 1 > /sys/devices/system/cpu/cpu1/online
        # perf record usleep 1
        # perf report --header-only | grep 'nrcpus \(online\|avail\)'
        # nrcpus online : 4
        # nrcpus avail : 4
      
      Acked-by: default avatarNamhyung Kim <namhyung@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: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Fixes: fbe96f29 ("perf tools: Make perf.data more self-descriptive (v8)")
      Link: http://lkml.kernel.org/r/20150911153323.GP23511@kernel.org
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      caa47047
  9. Sep 11, 2015
  10. Sep 08, 2015
  11. Sep 05, 2015
    • Andy Lutomirski's avatar
      x86/vm86: Block non-root vm86(old) if mmap_min_addr != 0 · 76fc5e7b
      Andy Lutomirski authored
      
      
      vm86 exposes an interesting attack surface against the entry
      code. Since vm86 is mostly useless anyway if mmap_min_addr != 0,
      just turn it off in that case.
      
      There are some reports that vbetool can work despite setting
      mmap_min_addr to zero.  This shouldn't break that use case,
      as CAP_SYS_RAWIO already overrides mmap_min_addr.
      
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      76fc5e7b
  12. Sep 04, 2015
  13. Sep 02, 2015
    • Adrian Hunter's avatar
      perf tools: Fix use of wrong event when processing exit events · 53ff6bc3
      Adrian Hunter authored
      
      
      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: default avatarAdrian 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.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      53ff6bc3
    • Jiri Olsa's avatar
      perf tools: Fix parse_events_add_pmu caller · 5ad4da43
      Jiri Olsa authored
      
      
      Following commit changed parse_events_add_pmu interface:
        36adec85 perf tools: Change parse_events_add_pmu interface
      
      but forgot to change one caller. Because of lessen compilation rules for
      the bison parser, the compiler did not warn on that.
      
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Raphael Beamonte <raphael.beamonte@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Fixes: 36adec85 ("perf tools: Change parse_events_add_pmu interface")
      Link: http://lkml.kernel.org/r/1441180605-24737-2-git-send-email-jolsa@kernel.org
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      5ad4da43
  14. Sep 01, 2015
Loading