Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 17 2月, 2018 1 次提交
  3. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      由 Greg Kroah-Hartman 提交于 
      Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  5. 19 7月, 2017 4 次提交
  7. 09 6月, 2017 1 次提交
  9. 25 4月, 2017 2 次提交
  11. 20 4月, 2017 6 次提交
  13. 28 3月, 2017 2 次提交
    • T
      perf buildid: Do not assume that readlink() returns a null terminated string · 5a234211
      由 Tommi Rantala 提交于 
      Valgrind was complaining:

  $ valgrind ./perf list >/dev/null
  ==11643== Memcheck, a memory error detector
  ==11643== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
  ==11643== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
  ==11643== Command: ./perf list
  ==11643==
  ==11643== Conditional jump or move depends on uninitialised value(s)
  ==11643==    at 0x4C30620: rindex (vg_replace_strmem.c:199)
  ==11643==    by 0x49DAA9: build_id_cache__origname (build-id.c:198)
  ==11643==    by 0x49E1C7: build_id_cache__valid_id (build-id.c:222)
  ==11643==    by 0x49E1C7: build_id_cache__list_all (build-id.c:507)
  ==11643==    by 0x4B9C8F: print_sdt_events (parse-events.c:2067)
  ==11643==    by 0x4BB0B3: print_events (parse-events.c:2313)
  ==11643==    by 0x439501: cmd_list (builtin-list.c:53)
  ==11643==    by 0x497150: run_builtin (perf.c:359)
  ==11643==    by 0x428CE0: handle_internal_command (perf.c:421)
  ==11643==    by 0x428CE0: run_argv (perf.c:467)
  ==11643==    by 0x428CE0: main (perf.c:614)
  [...]

Additionally, a zero length result from readlink() is not very interesting.
Signed-off-by: NTommi Rantala <tommi.t.rantala@nokia.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20170322130624.21881-3-tommi.t.rantala@nokia.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5a234211
    • T
      perf buildid: Do not update SDT cache with null filename · 2ccc2202
      由 Tommi Rantala 提交于 
      Valgrind was complaining:

  ==2633== Syscall param open(filename) points to unaddressable byte(s)
  ==2633==    at 0x5281CC0: __open_nocancel (syscall-template.S:84)
  ==2633==    by 0x537D38: open (fcntl2.h:53)
  ==2633==    by 0x537D38: get_sdt_note_list (symbol-elf.c:2017)
  ==2633==    by 0x5396FD: probe_cache__scan_sdt (probe-file.c:700)
  ==2633==    by 0x49EA2C: build_id_cache__add_sdt_cache (build-id.c:625)
  ==2633==    by 0x49EA2C: build_id_cache__add_s (build-id.c:697)
  ==2633==    by 0x49EE72: build_id_cache__add_b (build-id.c:717)
  ==2633==    by 0x49EE72: dso__cache_build_id (build-id.c:782)
  ==2633==    by 0x49F190: __dsos__cache_build_ids (build-id.c:793)
  ==2633==    by 0x49F190: machine__cache_build_ids (build-id.c:801)
  ==2633==    by 0x49F190: perf_session__cache_build_ids (build-id.c:815)
  ==2633==    by 0x4CD4F2: write_build_id (header.c:165)
  ==2633==    by 0x4D26F7: do_write_feat (header.c:2296)
  ==2633==    by 0x4D26F7: perf_header__adds_write (header.c:2335)
  ==2633==    by 0x4D26F7: perf_session__write_header (header.c:2414)
  ==2633==    by 0x43B324: __cmd_record (builtin-record.c:1154)
  ==2633==    by 0x43B324: cmd_record (builtin-record.c:1839)
  ==2633==    by 0x455A07: __cmd_record (builtin-kmem.c:1868)
  ==2633==    by 0x455A07: cmd_kmem (builtin-kmem.c:1944)
  ==2633==    by 0x497150: run_builtin (perf.c:359)
  ==2633==    by 0x428CE0: handle_internal_command (perf.c:421)
  ==2633==    by 0x428CE0: run_argv (perf.c:467)
  ==2633==    by 0x428CE0: main (perf.c:614)
  ==2633==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
Signed-off-by: NTommi Rantala <tommi.t.rantala@nokia.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tommi Rantala <tommi.t.rantala@nokia.com>
Link: http://lkml.kernel.org/r/20170322130624.21881-2-tommi.t.rantala@nokia.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2ccc2202
  15. 29 9月, 2016 1 次提交
  17. 14 7月, 2016 2 次提交
    • M
      perf probe: Support @BUILDID or @file suffix for SDT events · a598180a
      由 Masami Hiramatsu 提交于 
      Support @BUILDID or @file suffix for SDT events. This allows perf to add
probes on SDTs/pre-cached events on given FILE or the file which has
given BUILDID (also, this complements BUILDID.)

For example, both gcc and libstdc++ has same SDTs as below.  If you
would like to add a probe on sdt_libstdcxx:catch on gcc, you can do as
below.

  ----
  # perf list sdt | tail -n 6
    sdt_libstdcxx:catch@/usr/bin/gcc(0cc207fc4b27)     [SDT event]
    sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
    sdt_libstdcxx:rethrow@/usr/bin/gcc(0cc207fc4b27)   [SDT event]
    sdt_libstdcxx:rethrow@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
    sdt_libstdcxx:throw@/usr/bin/gcc(0cc207fc4b27)     [SDT event]
    sdt_libstdcxx:throw@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
  # perf probe -a %sdt_libstdcxx:catch@0cc
  Added new event:
    sdt_libstdcxx:catch  (on %catch in /usr/bin/gcc)

  You can now use it in all perf tools, such as:

  	perf record -e sdt_libstdcxx:catch -aR sleep 1
  ----

Committer note:

Doing the full sequence of steps to get the results above:

With a clean build-id cache:

  [root@jouet ~]# rm -rf ~/.debug/
  [root@jouet ~]# perf list sdt

  List of pre-defined events (to be used in -e):

  [root@jouet ~]#

No events whatsoever, then, we can add all events in gcc to the build-id
cache, doing a --add + --dry-run:

  [root@jouet ~]# perf probe --dry-run --cache -x /usr/bin/gcc --add %sdt_libstdcxx:\*
  Added new events:
    sdt_libstdcxx:throw  (on %* in /usr/bin/gcc)
    sdt_libstdcxx:rethrow (on %* in /usr/bin/gcc)
    sdt_libstdcxx:catch  (on %* in /usr/bin/gcc)

  You can now use it in all perf tools, such as:

	perf record -e sdt_libstdcxx:catch -aR sleep 1

  [root@jouet ~]#

It really didn't add any events, it just cached them:

  [root@jouet ~]# perf probe -l
  [root@jouet ~]#

We can see that it was cached as:

  [root@jouet ~]# ls -la ~/.debug/usr/bin/gcc/9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2/
  total 976
  drwxr-xr-x. 2 root root   4096 Jul 13 21:47 .
  drwxr-xr-x. 3 root root   4096 Jul 13 21:47 ..
  -rwxr-xr-x. 4 root root 985912 Jun 22 18:52 elf
  -rw-r--r--. 1 root root    303 Jul 13 21:47 probes
  [root@jouet ~]# file ~/.debug/usr/bin/gcc/9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2/elf
  /root/.debug/usr/bin/gcc/9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2/elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2, stripped
  [root@jouet ~]# cat ~/.debug/usr/bin/gcc/9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2/probes
  %sdt_libstdcxx:throw=throw
  p:sdt_libstdcxx/throw /usr/bin/gcc:0x71ffd
  %sdt_libstdcxx:rethrow=rethrow
  p:sdt_libstdcxx/rethrow /usr/bin/gcc:0x720b8
  %sdt_libstdcxx:catch=catch
  p:sdt_libstdcxx/catch /usr/bin/gcc:0x7307f
  %sdt_libgcc:unwind=unwind
  p:sdt_libgcc/unwind /usr/bin/gcc:0x7eec0
  #sdt_libstdcxx:*=%*
  [root@jouet ~]#

Ok, now we can use 'perf probe' to refer to those cached entries as:

  Humm, nope, doing as above we end up with:

  [root@jouet ~]# perf probe -a %sdt_libstdcxx:catch
  Semantic error :* is bad for event name -it must follow C symbol-naming rule.
    Error: Failed to add events.
  [root@jouet ~]#

But it worked at some point, lets try not using --dry-run:

Resetting everything:

  # rm -rf ~/.debug/
  # perf probe -d *:*
  # perf probe -l
  # perf list sdt

    List of pre-defined events (to be used in -e):

  #

Ok, now it cached everything, even things we haven't asked it to
(sdt_libgcc:unwind):

  [root@jouet ~]# perf probe -x /usr/bin/gcc --add %sdt_libstdcxx:\*
  Added new events:
    sdt_libstdcxx:throw  (on %* in /usr/bin/gcc)
    sdt_libstdcxx:rethrow (on %* in /usr/bin/gcc)
    sdt_libstdcxx:catch  (on %* in /usr/bin/gcc)

  You can now use it in all perf tools, such as:

	perf record -e sdt_libstdcxx:catch -aR sleep 1

  [root@jouet ~]# perf list sdt

  List of pre-defined events (to be used in -e):

    sdt_libgcc:unwind                                  [SDT event]
    sdt_libstdcxx:catch                                [SDT event]
    sdt_libstdcxx:rethrow                              [SDT event]
    sdt_libstdcxx:throw                                [SDT event]
  [root@jouet ~]#

And we have the events in place:

  [root@jouet ~]# perf probe -l
    sdt_libstdcxx:catch  (on execute_cfa_program+1551@../../../libgcc/unwind-dw2.c in /usr/bin/gcc)
    sdt_libstdcxx:rethrow (on d_print_subexpr+280@libsupc++/cp-demangle.c in /usr/bin/gcc)
    sdt_libstdcxx:throw  (on d_print_subexpr+93@libsupc++/cp-demangle.c in /usr/bin/gcc)
  [root@jouet ~]#

And trying to use them at least has 'perf trace --event sdt*:*' working.

Then, if we try to add the ones in libstdc++:

  [root@jouet ~]# perf probe -x /usr/lib64/libstdc++.so.6 -a %sdt_libstdcxx:\*
  Error: event "catch" already exists.
   Hint: Remove existing event by 'perf probe -d'
         or force duplicates by 'perf probe -f'
         or set 'force=yes' in BPF source.
    Error: Failed to add events.
  [root@jouet ~]#

Doesn't work, dups, but at least this served to, unbeknownst to the user, add
the SDT probes in /usr/lib64/libstdc++.so.6!

  [root@jouet ~]# perf list sdt

  List of pre-defined events (to be used in -e):

    sdt_libgcc:unwind                                  [SDT event]
    sdt_libstdcxx:catch@/usr/bin/gcc(9a0730e2bcc6)     [SDT event]
    sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
    sdt_libstdcxx:rethrow@/usr/bin/gcc(9a0730e2bcc6)   [SDT event]
    sdt_libstdcxx:rethrow@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
    sdt_libstdcxx:throw@/usr/bin/gcc(9a0730e2bcc6)     [SDT event]
    sdt_libstdcxx:throw@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
  [root@jouet ~]#

Now we should be able to get to the original cset comment, if we remove all
SDTs events in place, not from the cache, from the kernel, where it was set up as:

  [root@jouet ~]# ls -la /sys/kernel/debug/tracing/events/sdt_libstdcxx/
  total 0
  drwxr-xr-x.  5 root root 0 Jul 13 22:00 .
  drwxr-xr-x. 80 root root 0 Jul 13 21:56 ..
  drwxr-xr-x.  2 root root 0 Jul 13 22:00 catch
  -rw-r--r--.  1 root root 0 Jul 13 22:00 enable
  -rw-r--r--.  1 root root 0 Jul 13 22:00 filter
  drwxr-xr-x.  2 root root 0 Jul 13 22:00 rethrow
  drwxr-xr-x.  2 root root 0 Jul 13 22:00 throw
  [root@jouet ~]#

  [root@jouet ~]# head -2 /sys/kernel/debug/tracing/events/sdt_libstdcxx/throw/format
  name: throw
  ID: 2059
  [root@jouet ~]#

Now to remove it:

  [root@jouet ~]# perf probe -d sdt_libstdc*:*
  Removed event: sdt_libstdcxx:catch
  Removed event: sdt_libstdcxx:rethrow
  Removed event: sdt_libstdcxx:throw
  [root@jouet ~]#

Which caused:

  [root@jouet ~]# ls -la /sys/kernel/debug/tracing/events/sdt_libstdcxx/
  ls: cannot access '/sys/kernel/debug/tracing/events/sdt_libstdcxx/': No such file or directory
  [root@jouet ~]#

Ok, now we can do:

  [root@jouet ~]# perf list sdt_libstdcxx:catch

  List of pre-defined events (to be used in -e):

    sdt_libstdcxx:catch@/usr/bin/gcc(9a0730e2bcc6)     [SDT event]
    sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
  [root@jouet ~]#

So, these are not really 'pre-defined events', i.e. we can't use them with
'perf record --event':

  [root@jouet ~]# perf record --event sdt_libstdcxx:catch*
  event syntax error: 'sdt_libstdcxx:catch*'
                       \___ unknown tracepoint

  Error:	File /sys/kernel/debug/tracing/events/sdt_libstdcxx/catch* not found.
  Hint:	Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
<SNIP>
  [root@jouet ~]#

To have it really pre-defined we must use perf probe to get its definition from
the cache and set it up in the kernel, creating the tracepoint to _then_ use it
with 'perf record --event':

  [root@jouet ~]# perf probe -a sdt_libstdcxx:catch
  Semantic error :There is non-digit char in line number.
  <SNIP>

Oops, there is another gotcha here, we need that pesky '%' character:

  [root@jouet ~]# perf probe -a %sdt_libstdcxx:catch
  Added new events:
    sdt_libstdcxx:catch  (on %catch in /usr/bin/gcc)
    sdt_libstdcxx:catch_1 (on %catch in /usr/lib64/libstdc++.so.6.0.22)

  You can now use it in all perf tools, such as:

	perf record -e sdt_libstdcxx:catch_1 -aR sleep 1

  [root@jouet ~]#

But then we added _two_ events, one with the name we expected, the other one
with a _ added, when doing the analysis we need to pay attention to who maps to
who.

And here is where we get to the point of this patch, which is to be able to
disambiguate those definitions for 'catch' in the build-id cache, but first we need
remove those events we just added:

[root@jouet ~]# perf probe -d %sdt_libstdcxx:catch

Oops, that didn't remove anything, we need to _remove_ that % char in this case:

  [root@jouet ~]# perf probe -d sdt_libstdcxx:catch
  Removed event: sdt_libstdcxx:catch

And we need to remove the other event added, i.e. I forgot to add a * at the end:

  [root@jouet ~]# perf probe -d sdt_libstdcxx:catch*
  Removed event: sdt_libstdcxx:catch_1
  [root@jouet ~]#

Ok, disambiguating it using what is in this patch:

  [root@jouet ~]# perf list sdt_libstdcxx:catch

  List of pre-defined events (to be used in -e):

    sdt_libstdcxx:catch@/usr/bin/gcc(9a0730e2bcc6)     [SDT event]
    sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
  [root@jouet ~]#
  [root@jouet ~]# perf probe -a %sdt_libstdcxx:catch@9a07
  Added new event:
    sdt_libstdcxx:catch  (on %catch in /usr/bin/gcc)

  You can now use it in all perf tools, such as:

	perf record -e sdt_libstdcxx:catch -aR sleep 1

  [root@jouet ~]# perf probe -l
    sdt_libstdcxx:catch  (on execute_cfa_program+1551@../../../libgcc/unwind-dw2.c in /usr/bin/gcc)
  [root@jouet ~]#

Yeah, it works! But we need to try and simplify this :-)

Update: Some aspects of this simplification take place in the following
        patches.
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/146831793746.17065.13065062753978236612.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a598180a
    • M
      perf probe: Make --list show only available cached events · c3492a3a
      由 Masami Hiramatsu 提交于 
      Make "perf probe --cache --list" show only available cached events by
checking build-id validity.

E.g. without this patch:
  ----
  $ ./perf probe --cache --add oldevent=cmd_probe
  $ make #(to update ./perf)
  $ ./perf probe --cache --add newevent=cmd_probe
  $ ./perf probe --cache --list
  /home/mhiramat/ksrc/linux/tools/perf/perf (061e90539bac69
  probe_perf:newevent=cmd_probe
  /home/mhiramat/ksrc/linux/tools/perf/perf (c2e44d614e33e1
  probe_perf:oldevent=cmd_probe
  ----
It shows both of old and new events but user can not use old one.
With this;
  ----
  $ ./perf probe --cache -l
  /home/mhiramat/ksrc/linux/tools/perf/perf (061e90539bac69
  probe_perf:newevent=cmd_probe
  ----

This shows only new events which are on the existing binary.
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/146831789417.17065.17896487479879669610.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c3492a3a
  19. 13 7月, 2016 1 次提交
    • A
      perf tools: Add feature detection for gelf_getnote() · 1c1a3a47
      由 Arnaldo Carvalho de Melo 提交于 
      That is not present on some libelf implementations, such as the one used
in Alpine Linux: libelf-0.8.13.

This ends up disabling the SDT code, that relies on this function.

One alternative would be to provide an weak fallback implementation or
the open coded variant used by the buildid sysfs notes reading code.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-82lh22ybedy9b9lych8xj12g@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1c1a3a47
  21. 05 7月, 2016 1 次提交
    • M
      perf buildid-cache: Scan and import user SDT events to probe cache · 6430a94e
      由 Masami Hiramatsu 提交于 
      perf buildid-cache --add <binary> scans given binary and add
the SDT events to probe cache. "sdt_" prefix is appended for
all SDT providers to avoid event-name clash with other pre-defined
events. It is possible to use the cached SDT events as other cached
events, via perf probe --add "sdt_<provider>:<event>=<event>".

e.g.
  ----
  # perf buildid-cache --add /lib/libc-2.17.so
  # perf probe --cache --list | head -n 5
  /usr/lib/libc-2.17.so (a6fb821bdf53660eb2c29f778757aef294d3d392):
  sdt_libc:setjmp=setjmp
  sdt_libc:longjmp=longjmp
  sdt_libc:longjmp_target=longjmp_target
  sdt_libc:memory_heap_new=memory_heap_new
  # perf probe -x /usr/lib/libc-2.17.so \
    -a sdt_libc:memory_heap_new=memory_heap_new
  Added new event:
    sdt_libc:memory_heap_new (on memory_heap_new
   in /usr/lib/libc-2.17.so)

  You can now use it in all perf tools, such as:

          perf record -e sdt_libc:memory_heap_new -aR sleep 1

  # perf probe -l
    sdt_libc:memory_heap_new (on new_heap+183 in /usr/lib/libc-2.17.so)
  ----

Note that SDT event entries in probe-cache file is somewhat different
from normal cached events. Normal one starts with "#", but SDTs are
starting with "%".
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/146736025058.27797.13043265488541434502.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6430a94e
  23. 01 7月, 2016 1 次提交
  25. 14 6月, 2016 1 次提交
  27. 07 6月, 2016 1 次提交
    • W
      perf tools: Fix crash in build_id_cache__kallsyms_path() · c58c49ac
      由 Wang Nan 提交于 
      build_id_cache__kallsyms_path() accepts a string buffer but also allocs
a buffer using asnprintf. Unfortunately, the its only user passes it a
stack-allocated buffer. Freeing it causes crashes like this:

  $ perf script
  *** Error in `/home/wangnan/perf': free(): invalid pointer: 0x00007fffffff9630 ***
  ======= Backtrace: =========
  lib64/libc.so.6(+0x6eeef)[0x7ffff5dbaeef]
  lib64/libc.so.6(+0x78cae)[0x7ffff5dc4cae]
  lib64/libc.so.6(+0x79987)[0x7ffff5dc5987]
  /home/w00229757/perf(build_id_cache__kallsyms_path+0x6b)[0x49681b]
  /home/w00229757/perf[0x4bdd40]
  /home/w00229757/perf(dso__load+0xa3a)[0x4c048a]
  /home/w00229757/perf(map__load+0x6f)[0x4d561f]
  /home/w00229757/perf(thread__find_addr_map+0x235)[0x49e935]
  /home/w00229757/perf(machine__resolve+0x7d)[0x49ec6d]
  /home/w00229757/perf[0x4555a8]
  /home/w00229757/perf[0x4d9507]
  /home/w00229757/perf[0x4d9e80]
  /home/w00229757/perf(ordered_events__flush+0x354)[0x4dd444]
  /home/w00229757/perf(perf_session__process_events+0x3d0)[0x4dc140]
  /home/w00229757/perf(cmd_script+0x12b0)[0x4592e0]
  /home/w00229757/perf[0x4911f1]
  /home/w00229757/perf(main+0x68f)[0x4352ef]
  /lib64/libc.so.6(__libc_start_main+0xf5)[0x7ffff5d6dbd5]
  /home/w00229757/perf[0x435415]
  ======= Memory map: ========

This patch simplifies build_id_cache__kallsyms_path(), not even
considering allocating a string buffer, so never frees anything. Its
caller should manage memory allocation.
Signed-off-by: NWang Nan <wangnan0@huawei.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Fixes: 01412261 ("perf buildid-cache: Use path/to/bin/buildid/elf instead of path/to/bin/buildid")
Link: http://lkml.kernel.org/r/1465271678-7392-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c58c49ac
  29. 31 5月, 2016 1 次提交
  31. 17 5月, 2016 1 次提交
    • H
      perf symbols: Store vdso buildid unconditionally · 6ae98ba6
      由 He Kuang 提交于 
      When unwinding callchains on a different machine, vdso info should be
available so the unwind process won't be interrupted if address falls
into vdso region. But in most cases, the addresses of sample events are
not in vdso range, the buildid of a zero hit vdso won't be stored into
perf.data.

This patch stores vdso buildid regardless of whether the vdso is hit or
not.
Signed-off-by: NHe Kuang <hekuang@huawei.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1463042596-61703-3-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6ae98ba6
  33. 12 5月, 2016 1 次提交
  35. 25 4月, 2016 1 次提交
    • A
      perf buildid: Fix off-by-one in write_buildid() · 70a2cba9
      由 Andrey Ryabinin 提交于 
      write_buildid() increments 'name_len' with intention to take into
account trailing zero byte. However, 'name_len' was already incremented
in machine__write_buildid_table() before.  So this leads to
out-of-bounds read in do_write():

  $ ./perf record sleep 0
  [ perf record: Woken up 1 times to write data ]
  =================================================================
  ==15899==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000099fc92 at pc 0x7f1aa9c7eab5 bp 0x7fff940f84d0 sp 0x7fff940f7c78
  READ of size 19 at 0x00000099fc92 thread T0
      #0 0x7f1aa9c7eab4  (/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libasan.so.2+0x44ab4)
      #1 0x649c5b in do_write util/header.c:67
      #2 0x649c5b in write_padded util/header.c:82
      #3 0x57e8bc in write_buildid util/build-id.c:239
      #4 0x57e8bc in machine__write_buildid_table util/build-id.c:278
  ...

  0x00000099fc92 is located 0 bytes to the right of global variable '*.LC99' defined in 'util/symbol.c' (0x99fc80) of size 18
    '*.LC99' is ascii string '[kernel.kallsyms]'
  ...

  Shadow bytes around the buggy address:
    0x00008012bf80: f9 f9 f9 f9 00 00 00 00 00 00 03 f9 f9 f9 f9 f9
  =>0x00008012bf90: 00 00[02]f9 f9 f9 f9 f9 00 00 00 00 00 05 f9 f9
    0x00008012bfa0: f9 f9 f9 f9 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00
Signed-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1461053847-5633-1-git-send-email-aryabinin@virtuozzo.com
[ Remove the off-by one at the origin, to keep len(s) == strlen(s) assumption ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      70a2cba9
  37. 23 3月, 2016 1 次提交
  39. 12 2月, 2016 1 次提交
    • W
      perf symbols: Fix symbols searching for module in buildid-cache · e7ee4047
      由 Wang Nan 提交于 
      Before this patch, if a sample is triggered inside a module not in
/lib/modules/`uname -r`/, even if the module is in buildid-cache, 'perf
report' will still be unable to find the correct symbol.  For example:

  # rm -rf ~/.debug/
  # perf buildid-cache -a ./mymodule.ko
  # perf probe -m ./mymodule.ko -a get_mymodule_val
  Added new event:
    probe:get_mymodule_val (on get_mymodule_val in mymodule)

  You can now use it in all perf tools, such as:

 	perf record -e probe:get_mymodule_val -aR sleep 1

  # perf record -e probe:get_mymodule_val cat /proc/mymodule
  mymodule:3
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ]

  # perf report --stdio
  [SNIP]
  #
  # Overhead  Command  Shared Object     Symbol
  # ........  .......  ................  ......................
  #
    100.00%  cat      [mymodule]        [k] 0x0000000000000001

  # perf report -vvvv --stdio
  dso__load_sym: adjusting symbol: st_value: 0 sh_addr: 0 sh_offset: 0x70
  symbol__new: get_mymodule_val 0x70-0x8a
  [SNIP]

This is caused by dso__load() -> dso__load_sym(). In dso__load(), kmod
is true only when its file is found in some well know directories. All
files loaded from buildid-cache are treated as user programs. Following
dso__load_sym() set map->pgoff incorrectly.

This patch gives kernel modules in buildid-cache a chance to adjust
value of kmod. After dso__load() get the type of symbols, if it is
buildid, check the last 3 chars of original filename against '.ko', and
adjust the value of kmod if the file is a kernel module.
Signed-off-by: NWang Nan <wangnan0@huawei.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Cody P Schafer <dev@codyps.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jeremie Galarneau <jeremie.galarneau@efficios.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kirill Smelkov <kirr@nexedi.com>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1454680939-24963-3-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e7ee4047
  41. 30 1月, 2016 1 次提交
    • W
      perf buildid: Fix cpumode of buildid event · fd786fac
      由 Wang Nan 提交于 
      There is a nasty confusion that, for kernel module, dso->kernel is not
necessary to be DSO_TYPE_KERNEL or DSO_TYPE_GUEST_KERNEL.  These two
enums are for vmlinux. See thread [1]. We tried to fix this part but it
is costy.

Code machine__write_buildid_table() is another unfortunate function fall
into this trap that, when issuing buildid event for a kernel module,
cpumode it gives to the event is PERF_RECORD_MISC_USER, not
PERF_RECORD_MISC_KERNEL.

However, even with this bug, most of the time it doesn't causes real
problem. I find this issue when trying to use a perf before commit
3d39ac53 ("perf machine: No need to have two DSOs lists") to parse a
perf.data generated by newest perf.

[1] https://lkml.org/lkml/2015/9/21/908Signed-off-by: NWang Nan <wangnan0@huawei.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1454089251-203152-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fd786fac
  43. 07 12月, 2015 1 次提交
    • M
      perf buildid-list: Show running kernel build id fix · 7375e151
      由 Michael Petlan 提交于 
      The --kernel option of perf buildid-list tool should show the running
kernel buildid.  The functionality has been lost during other changes of
the related code.

The build_id__sprintf() function should return length of the build-id
string,  but it was the length of the build-id raw data instead. Due to
that, some return value checking caused that the final string was not
printed out.

With this patch the build_id__sprintf() returns the correct value, so
the --kernel option works again.

Before:

	# perf buildid-list --kernel
	#

After:

	# perf buildid-list --kernel
	972c1edab5bdc06cc224af45d510af662a3c6972
	#
Signed-off-by: NMichael Petlan <mpetlan@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
LPU-Reference: 1448632089.24573.114.camel@redhat.com
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7375e151
  45. 27 11月, 2015 1 次提交
    • M
      perf buildid-list: Show running kernel build id fix · c4e07949
      由 Michael Petlan 提交于 
      The --kernel option of perf buildid-list tool should show the running
kernel buildid.  The functionality has been lost during other changes of
the related code.

The build_id__sprintf() function should return length of the build-id
string,  but it was the length of the build-id raw data instead. Due to
that, some return value checking caused that the final string was not
printed out.

With this patch the build_id__sprintf() returns the correct value, so
the --kernel option works again.

Before:

	# perf buildid-list --kernel
	#

After:

	# perf buildid-list --kernel
	972c1edab5bdc06cc224af45d510af662a3c6972
	#
Signed-off-by: NMichael Petlan <mpetlan@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
LPU-Reference: 1448632089.24573.114.camel@redhat.com
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c4e07949
  47. 13 11月, 2015 1 次提交
  49. 29 8月, 2015 1 次提交
  51. 21 7月, 2015 1 次提交
  53. 20 7月, 2015 1 次提交
  55. 29 5月, 2015 1 次提交
  57. 09 5月, 2015 1 次提交
    • A
      perf machine: Protect the machine->threads with a rwlock · b91fc39f
      由 Arnaldo Carvalho de Melo 提交于 
      In addition to using refcounts for the struct thread lifetime
management, we need to protect access to machine->threads from
concurrent access.

That happens in 'perf top', where a thread processes events, inserting
and deleting entries from that rb_tree while another thread decays
hist_entries, that end up dropping references and ultimately deleting
threads from the rb_tree and releasing its resources when no further
hist_entry (or other data structures, like in 'perf sched') references
it.

So the rule is the same for refcounts + protected trees in the kernel,
get the tree lock, find object, bump the refcount, drop the tree lock,
return, use object, drop the refcount if no more use of it is needed,
keep it if storing it in some other data structure, drop when releasing
that data structure.

I.e. pair "t = machine__find(new)_thread()" with a "thread__put(t)", and
"perf_event__preprocess_sample(&al)" with "addr_location__put(&al)".

The addr_location__put() one is because as we return references to
several data structures, we may end up adding more reference counting
for the other data structures and then we'll drop it at
addr_location__put() time.
Acked-by: NDavid Ahern <dsahern@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Don Zickus <dzickus@redhat.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>
Link: http://lkml.kernel.org/n/tip-bs9rt4n0jw3hi9f3zxyy3xln@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b91fc39f