Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 8月, 2017 5 次提交
  3. 22 8月, 2017 10 次提交
  5. 18 8月, 2017 12 次提交
  7. 17 8月, 2017 1 次提交
  9. 16 8月, 2017 6 次提交
  11. 15 8月, 2017 3 次提交
    • A
      perf test shell vfs_getname: Skip for tools built with NO_LIBDWARF=1 · 2b728861
      由 Arnaldo Carvalho de Melo 提交于 
      If that is the case, or if the required lib is not present, e.g.
elfutils-devel in Fedora systems, then just skip the tests requiring
DWARF analysis.

Before:

  # rpm -e elfutils-devel
  # perf test ping vfs_getname
  60: Use vfs_getname probe to get syscall args filenames   : FAILED!
  61: probe libc's inet_pton & backtrace it with ping       : Ok
  62: Check open filename arg using perf trace + vfs_getname: FAILED!
  63: Add vfs_getname probe to get syscall args filenames   : FAILED!
  #

After:

  # perf test vfs_getname
  60: Use vfs_getname probe to get syscall args filenames   : Skip
  62: Check open filename arg using perf trace + vfs_getname: Skip
  63: Add vfs_getname probe to get syscall args filenames   : Skip
  #

Then, reinstalling elfutils-devel, rebuilding the tool and running
again:

  # perf test vfs_getname
  60: Use vfs_getname probe to get syscall args filenames   : Ok
  62: Check open filename arg using perf trace + vfs_getname: Ok
  63: Add vfs_getname probe to get syscall args filenames   : Ok
  #
Reported-by: NKim Phillips <kim.phillips@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-d67tvn401fxrwr97pu5ihfb1@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2b728861
    • A
      perf test shell: Check if 'perf probe' is available, skip tests if not · 1ad5a182
      由 Arnaldo Carvalho de Melo 提交于 
      Add a library function that checks if 'perf probe' is built into the
tool being tested, skipping tests that need it.

Testing it on a system after removing the library needed to build
'probe' as a perf subcommand:

  # perf test ping vfs_getname
  59: Use vfs_getname probe to get syscall args filenames   : Skip
  60: probe libc's inet_pton & backtrace it with ping       : Skip
  61: Check open filename arg using perf trace + vfs_getname: Skip
  62: Add vfs_getname probe to get syscall args filenames   : Skip
  # perf probe
  perf: 'probe' is not a perf-command. See 'perf --help'.
  #

Now reinstalling elfutils-libelf-devel on this Fedora 26 system to
rebuild perf and then retest this:

  # perf test ping vfs_getname
  60: Use vfs_getname probe to get syscall args filenames   : Ok
  61: probe libc's inet_pton & backtrace it with ping       : Ok
  62: Check open filename arg using perf trace + vfs_getname: Ok
  63: Add vfs_getname probe to get syscall args filenames   : Ok
  #
Reported-by: NKim Phillips <kim.phillips@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-ctdck2gzsskqhjzu3ebb62zm@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1ad5a182
    • A
      perf tests shell: Remove duplicate skip_if_no_debuginfo() function · 06786963
      由 Arnaldo Carvalho de Melo 提交于 
      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-3zxjswdbs2au3ih0rino0iy1@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      06786963
  13. 12 8月, 2017 3 次提交
    • A
      perf test shell: Add uprobes + backtrace ping test · 8fc375d7
      由 Arnaldo Carvalho de Melo 提交于 
      Installs a probe on libc's inet_pton function, that will use uprobes,
then use 'perf trace' on a ping to localhost asking for just one packet
with the a backtrace 3 levels deep, check that it is what we expect.
This needs no debuginfo package, all is done using the libc ELF symtab
and the CFI info in the binaries.

Testing it:

  # perf test ping
  61: probe libc's inet_pton & backtrace it with ping       : Ok

In verbose mode:

  # perf test -v ping
  61: probe libc's inet_pton & backtrace it with ping       :
  --- start ---
  test child forked, pid 1007
  PING ::1(::1) 56 data bytes
  64 bytes from ::1: icmp_seq=1 ttl=64 time=0.058 ms
  --- ::1 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 0.058/0.058/0.058/0.000 ms
  0.000 probe_libc:inet_pton:(7f75fce12a20))
  __GI___inet_pton (/usr/lib64/libc-2.24.so)
  getaddrinfo (/usr/lib64/libc-2.24.so)
  _init (/usr/bin/ping)
  test child finished with 0
  ---- end ----
  probe libc's inet_pton & backtrace it with ping: Ok
  #

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-idrntt4nbg15aafu8hjmv7sk@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8fc375d7
    • T
      perf report: Fix module symbol adjustment for s390x · 4a084ecf
      由 Thomas Richter 提交于 
      The 'perf report' tool does not display the addresses of kernel module
symbols correctly.

For example symbol qeth_send_ipa_cmd in kernel module qeth.ko has this
relative address for function qeth_send_ipa_cmd():

  [root@s8360047 linux]# nm -g drivers/s390/net/qeth.ko | fgrep send_ipa_cmd
  0000000000013088 T qeth_send_ipa_cmd

The module is loaded at address:

  [root@s8360047 linux]# cat /sys/module/qeth/sections/.text
  0x000003ff80296d20
  [root@s8360047 linux]#

This should result in a start address of:

  0x13088 + 0x3ff80296d20 = 0x3ff802a9da8

Using crash to verify the address on a live system:

  [root@s8360046 linux]# crash vmlinux

  crash 7.1.9++
  Copyright (C) 2002-2016  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation

  [...]

  crash> mod -s qeth drivers/s390/net/qeth.ko
       MODULE       NAME        SIZE  OBJECT FILE
       3ff8028d700  qeth      151552  drivers/s390/net/qeth.ko
  crash> sym qeth_send_ipa_cmd
  3ff802a9da8 (T) qeth_send_ipa_cmd [qeth] /root/linux/drivers/s390/net/qeth_core_main.c: 2944
  crash>

Now perf report displays the address of symbol qeth_send_ipa_cmd:
symbol__new:

  qeth_send_ipa_cmd 0x130f0-0x132ce

There is a difference of 0x68 between the entry in the symbol table (see
nm command above) and perf. The difference is from the offset the .text
segment of qeth.ko:

  [root@s8360047 perf]# readelf -a drivers/s390/net/qeth.ko
  Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .note.gnu.build-i NOTE             0000000000000000  00000040
       0000000000000024  0000000000000000   A       0     0     4
  [ 2] .text             PROGBITS         0000000000000000  00000068
       000000000001c8a0  0000000000000000  AX       0     0     8

As seen the .text segment has an offset of 0x68 with start address 0x0.
Therefore 0x68 is added to the address of qeth_send_ipa_cmd and thus
0x13088 + 0x68 = 0x130f0 is displayed.

This is wrong, perf report needs to display the start address of symbol
qeth_send_ipa_cmd at 0x13088 + qeth.ko.text section start address.

The qeth.ko module .text start address is available in the qeth.ko DSO
map. Just identify the kernel module symbols and correct the addresses.

With the fix I see this correct address for symbol: symbol__new:
qeth_send_ipa_cmd 0x3ff802a9da8-0x3ff802a9f86
Signed-off-by: NThomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Reviewed-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Cc: Zvonko Kosic <zvonko.kosic@de.ibm.com>
LPU-Reference: 20170803134902.47207-1-tmricht@linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-q8lktlpoxb5e3dj52u1s1rw4@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4a084ecf
    • T
      perf record: Fix wrong size in perf_record_mmap for last kernel module · 9ad4652b
      由 Thomas Richter 提交于 
      During work on perf report for s390 I ran into the following issue:

0 0x318 [0x78]: PERF_RECORD_MMAP -1/0:
        [0x3ff804d6990(0xfffffc007fb2966f) @ 0]:
        x /lib/modules/4.12.0perf1+/kernel/drivers/s390/net/qeth_l2.ko

This is a PERF_RECORD_MMAP entry of the perf.data file with an invalid
module size for qeth_l2.ko (the s390 ethernet device driver).

Even a mainframe does not have 0xfffffc007fb2966f bytes of main memory.

It turned out that this wrong size is created by the perf record
command.  What happens is this function call sequence from
__cmd_record():

  perf_session__new():
    perf_session__create_kernel_maps():
      machine__create_kernel_maps():
        machine__create_modules():   Creates map for all loaded kernel modules.
          modules__parse():   Reads /proc/modules and extracts module name and
                              load address (1st and last column)
            machine__create_module():   Called for every module found in /proc/modules.
                              Creates a new map for every module found and enters
                              module name and start address into the map. Since the
                              module end address is unknown it is set to zero.

This ends up with a kernel module map list sorted by module start
addresses.  All module end addresses are zero.

Last machine__create_kernel_maps() calls function map_groups__fixup_end().
This function iterates through the maps and assigns each map entry's
end address the successor map entry start address. The last entry of the
map group has no successor, so ~0 is used as end to consume the remaining
memory.

Later __cmd_record calls function record__synthesize() which in turn calls
perf_event__synthesize_kernel_mmap() and perf_event__synthesize_modules()
to create PERF_REPORT_MMAP entries into the perf.data file.

On s390 this results in the last module qeth_l2.ko
(which has highest start address, see module table:
        [root@s8360047 perf]# cat /proc/modules
        qeth_l2 86016 1 - Live 0x000003ff804d6000
        qeth 266240 1 qeth_l2, Live 0x000003ff80296000
        ccwgroup 24576 1 qeth, Live 0x000003ff80218000
        vmur 36864 0 - Live 0x000003ff80182000
        qdio 143360 2 qeth_l2,qeth, Live 0x000003ff80002000
        [root@s8360047 perf]# )
to be the last entry and its map has an end address of ~0.

When the PERF_RECORD_MMAP entry is created for kernel module qeth_l2.ko
its start address and length is written. The length is calculated in line:
    event->mmap.len   = pos->end - pos->start;
and results in 0xffffffffffffffff - 0x3ff804d6990(*) = 0xfffffc007fb2966f

(*) On s390 the module start address is actually determined by a __weak function
named arch__fix_module_text_start() in machine__create_module().

I think this improvable. We can use the module size (2nd column of /proc/modules)
to get each loaded kernel module size and calculate its end address.
Only for map entries which do not have a valid end address (end is still zero)
we can use the heuristic we have now, that is use successor start address or ~0.
Signed-off-by: NThomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Reviewed-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Cc: Zvonko Kosic <zvonko.kosic@de.ibm.com>
LPU-Reference: 20170803134902.47207-2-tmricht@linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-nmoqij5b5vxx7rq2ckwu8iaj@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9ad4652b