1. 25 9月, 2015 1 次提交
    • A
      perf probe: Use existing routine to look for a kernel module by dso->short_name · 266fa2b2
      Arnaldo Carvalho de Melo 提交于
      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: NWang Nan <wangnan0@huawei.com>
      Acked-by: NMasami 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.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      266fa2b2
  2. 18 9月, 2015 3 次提交
    • 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
      Revert "perf symbols: Fix mismatched declarations for elf_getphdrnum" · 179f36dd
      Arnaldo Carvalho de Melo 提交于
      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: NVinson 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.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      179f36dd
  3. 17 9月, 2015 1 次提交
    • S
      perf stat: Fix per-pkg event reporting bug · 02d8dabc
      Stephane Eranian 提交于
      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: NStephane 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.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      02d8dabc
  4. 15 9月, 2015 12 次提交
  5. 13 9月, 2015 1 次提交
    • A
      perf header: Fixup reading of HEADER_NRCPUS feature · caa47047
      Arnaldo Carvalho de Melo 提交于
      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: NNamhyung 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.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      caa47047
  6. 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
  7. 02 9月, 2015 3 次提交
  8. 01 9月, 2015 4 次提交
    • S
      perf record: Add ability to name registers to record · bcc84ec6
      Stephane Eranian 提交于
      This patch modifies the -I/--int-regs option to enablepassing the name
      of the registers to sample on interrupt. Registers can be specified by
      their symbolic names. For instance on x86, --intr-regs=ax,si.
      
      The motivation is to reduce the size of the perf.data file and the
      overhead of sampling by only collecting the registers useful to a
      specific analysis. For instance, for value profiling, sampling only the
      registers used to passed arguements to functions.
      
      With no parameter, the --intr-regs still records all possible registers
      based on the architecture.
      
      To name registers, it is necessary to use the long form of the option,
      i.e., --intr-regs:
      
        $ perf record --intr-regs=si,di,r8,r9 .....
      
      To record any possible registers:
      
        $ perf record -I .....
        $ perf report --intr-regs ...
      
      To display the register, one can use perf report -D
      
      To list the available registers:
      
        $ perf record --intr-regs=\?
        available registers: AX BX CX DX SI DI BP SP IP FLAGS CS SS R8 R9 R10 R11 R12 R13 R14 R15
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.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/1441039273-16260-4-git-send-email-eranian@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bcc84ec6
    • S
      perf/x86: Add list of register names · c5e991ee
      Stephane Eranian 提交于
      This patch adds a way to locate a register identifier (PERF_X86_REG_*)
      based on its name, e.g., AX.
      
      This will be used by a subsequent patch to improved flexibility of perf
      record.
      Signed-off-by: NStephane 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/1441039273-16260-3-git-send-email-eranian@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c5e991ee
    • K
      perf evlist: Open event on evsel cpus and threads · d988d5ee
      Kan Liang 提交于
      An evsel may have different cpus and threads than the evlist it is in.
      
      Use it's own cpus and threads, when opening the evsel in 'perf record'.
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Link: http://lkml.kernel.org/r/1440138194-17001-1-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d988d5ee
    • A
      perf tools: Fix build on powerpc broken by pt/bts · 97db6206
      Adrian Hunter 提交于
      It is theoretically possible to process perf.data files created on x86
      and that contain Intel PT or Intel BTS data, on any other architecture,
      which is why it is possible for there to be build errors on powerpc
      caused by pt/bts.
      
      The errors were:
      
      	util/intel-pt-decoder/intel-pt-insn-decoder.c: In function ‘intel_pt_insn_decoder’:
      	util/intel-pt-decoder/intel-pt-insn-decoder.c:138:3: error: switch missing default case [-Werror=switch-default]
      	   switch (insn->immediate.nbytes) {
      	   ^
      	cc1: all warnings being treated as errors
      
      	linux-acme.git/tools/perf/perf-obj/libperf.a(libperf-in.o): In function `intel_pt_synth_branch_sample':
      	sources/linux-acme.git/tools/perf/util/intel-pt.c:871: undefined reference to `tsc_to_perf_time'
      	linux-acme.git/tools/perf/perf-obj/libperf.a(libperf-in.o): In function `intel_pt_sample':
      	sources/linux-acme.git/tools/perf/util/intel-pt.c:915: undefined reference to `tsc_to_perf_time'
      	sources/linux-acme.git/tools/perf/util/intel-pt.c:962: undefined reference to `tsc_to_perf_time'
      	linux-acme.git/tools/perf/perf-obj/libperf.a(libperf-in.o): In function `intel_pt_process_event':
      	sources/linux-acme.git/tools/perf/util/intel-pt.c:1454: undefined reference to `perf_time_to_tsc'
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1441046384-28663-1-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      97db6206
  9. 29 8月, 2015 6 次提交
  10. 26 8月, 2015 5 次提交
    • W
      perf probe: Support probing at absolute address · da15bd9d
      Wang Nan 提交于
      It should be useful to allow 'perf probe' probe at absolute offset of a
      target. For example, when (u)probing at a instruction of a shared object
      in a embedded system where debuginfo is not avaliable but we know the
      offset of that instruction by manually digging.
      
      This patch enables following perf probe command syntax:
      
        # perf probe 0xffffffff811e6615
      
      And
      
        # perf probe /lib/x86_64-linux-gnu/libc-2.19.so 0xeb860
      
      In the above example, we don't need a anchor symbol, so it is possible
      to compute absolute addresses using other methods and then use 'perf
      probe' to create the probing points.
      
      v1 -> v2:
        Drop the leading '+' in cmdline;
        Allow uprobing at offset 0x0;
        Improve 'perf probe -l' result when uprobe at area without debuginfo.
      
      v2 -> v3:
        Split bugfix to a separated patch.
      
      Test result:
      
        # perf probe 0xffffffff8119d175 %ax
        # perf probe sys_write %ax
        # perf probe /lib64/libc-2.18.so 0x0 %ax
        # perf probe /lib64/libc-2.18.so 0x5 %ax
        # perf probe /lib64/libc-2.18.so 0xd8e40 %ax
        # perf probe /lib64/libc-2.18.so __write %ax
        # perf probe /lib64/libc-2.18.so 0xd8e49 %ax
        # cat /sys/kernel/debug/tracing/uprobe_events
      
        p:probe_libc/abs_0 /lib64/libc-2.18.so:0x          (null) arg1=%ax
        p:probe_libc/abs_5 /lib64/libc-2.18.so:0x0000000000000005 arg1=%ax
        p:probe_libc/abs_d8e40 /lib64/libc-2.18.so:0x00000000000d8e40 arg1=%ax
        p:probe_libc/__write /lib64/libc-2.18.so:0x00000000000d8e40 arg1=%ax
        p:probe_libc/abs_d8e49 /lib64/libc-2.18.so:0x00000000000d8e49 arg1=%ax
      
        # cat /sys/kernel/debug/tracing/kprobe_events
      
        p:probe/abs_ffffffff8119d175 0xffffffff8119d175 arg1=%ax
        p:probe/sys_write _text+1692016 arg1=%ax
      
        # perf probe -l
      
        Failed to find debug information for address 5
          probe:abs_ffffffff8119d175 (on sys_write+5 with arg1)
          probe:sys_write      (on sys_write with arg1)
          probe_libc:__write   (on @unix/syscall-template.S:81 in /lib64/libc-2.18.so with arg1)
          probe_libc:abs_0     (on 0x0 in /lib64/libc-2.18.so with arg1)
          probe_libc:abs_5     (on 0x5 in /lib64/libc-2.18.so with arg1)
          probe_libc:abs_d8e40 (on @unix/syscall-template.S:81 in /lib64/libc-2.18.so with arg1)
          probe_libc:abs_d8e49 (on __GI___libc_write+9 in /lib64/libc-2.18.so with arg1)
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1440586666-235233-7-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      da15bd9d
    • W
      perf probe: Fix error reported when offset without function · 6c6e024f
      Wang Nan 提交于
      This patch fixes a bug that, when offset is provided but function is
      lost, parse_perf_probe_point() will give a "" string as function name,
      so the checking code at the end of parse_perf_probe_point() become
      useless.  For example:
      
        # perf probe +0x1234
        Failed to find symbol  in kernel
          Error: Failed to add events.
      
      After this patch:
      
        # perf probe +0x1234
        Semantic error :Offset requires an entry function.
          Error: Command Parse Error.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1440586666-235233-6-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6c6e024f
    • W
      perf probe: Fix list result when address is zero · be07afe9
      Wang Nan 提交于
      When manually added uprobe point with zero address, 'perf probe -l'
      reports error. For example:
      
        # echo p:probe_libc/abs_0 /path/to/lib.bin:0x0 arg1=%ax > \
                 /sys/kernel/debug/tracing/uprobe_events
      
        # perf probe -l
        Error: Failed to show event list.
      
      Probing at 0x0 is possible and useful when lib.bin is not a normal
      shared object but is manually mapped. However, in this case kernel
      report:
      
        # cat /sys/kernel/debug/tracing/uprobe_events
        p:probe_libc/abs_0 /path/to/lib.bin:0x          (null) arg1=%ax
      
      This patch supports the above kernel output.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1440586666-235233-5-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      be07afe9
    • W
      perf probe: Fix list result when symbol can't be found · 614e2fdb
      Wang Nan 提交于
      'perf probe -l' reports error if it is unable find symbol through
      address. Here is an example.
      
        # echo 'p:probe_libc/abs_5 /lib64/libc.so.6:0x5' >
                /sys/kernel/debug/tracing/uprobe_events
        # cat /sys/kernel/debug/tracing/uprobe_events
         p:probe_libc/abs_5 /lib64/libc.so.6:0x0000000000000005
        # perf probe -l
          Error: Failed to show event list
      
      Also, this situation triggers a logical inconsistency in
      convert_to_perf_probe_point() that, it returns ENOMEM but actually it
      never try strdup().
      
      This patch removes !tp->module && !is_kprobe condition, so it always
      uses address to build function name if symbol not found.
      
      Test result:
      
        # perf probe -l
          probe_libc:abs_5     (on 0x5 in /lib64/libc.so.6)
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1440586666-235233-4-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      614e2fdb
    • W
      perf probe: Prevent segfault when reading probe point with absolute address · e486367f
      Wang Nan 提交于
      'perf probe -l' panic if there is a manually inserted probing point with
      absolute address. For example:
      
        # echo 'p:probe/abs_ffffffff811e6615 0xffffffff811e6615' > /sys/kernel/debug/tracing/kprobe_events
        # perf probe -l
        Segmentation fault (core dumped)
      
      This patch fix this problem by considering the situation that
      "tp->symbol == NULL" in find_perf_probe_point_from_dwarf() and
      find_perf_probe_point_from_map().
      
      After this patch:
      
        # perf probe -l
        probe:abs_ffffffff811e6615 (on SyS_write+5@fs/read_write.c)
      
      And when debug info is missing:
      
        # rm -rf ~/.debug
        # mv /lib/modules/4.2.0-rc1+/build/vmlinux /lib/modules/4.2.0-rc1+/build/vmlinux.bak
        # perf probe -l
        probe:abs_ffffffff811e6615 (on sys_write+5)
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1440509256-193590-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e486367f
  11. 25 8月, 2015 3 次提交