linux-stable.git/tools/perf/util/thread.c, branch v6.4

perf map: Add helper for ->map_ip() and ->unmap_ip()

2023-04-07T01:10:17+00:00

Later changes will add reference count checking for struct map, add a
helper function to invoke the map_ip and unmap_ip function pointers. The
helper allows the reference count check to be in fewer places.

Committer notes:

Add missing conversions to:

  tools/perf/util/map.c
  tools/perf/util/cs-etm.c
  tools/perf/util/annotate.c
  tools/perf/arch/powerpc/util/sym-handling.c
  tools/perf/arch/s390/annotate/instructions.c

Signed-off-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Alexey Bayduraev 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: Andy Shevchenko 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: Dmitriy Vyukov 
Cc: Eric Dumazet 
Cc: German Gomez 
Cc: Hao Luo 
Cc: Ingo Molnar 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: John Garry 
Cc: Kajol Jain 
Cc: Kan Liang 
Cc: Leo Yan 
Cc: Madhavan Srinivasan 
Cc: Mark Rutland 
Cc: Masami Hiramatsu 
Cc: Miaoqian Lin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Riccardo Mancini 
Cc: Shunsuke Nakamura 
Cc: Song Liu 
Cc: Stephane Eranian 
Cc: Stephen Brennan 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Cc: Thomas Richter 
Cc: Yury Norov 
Link: https://lore.kernel.org/r/20230404205954.2245628-2-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

perf map: Add accessor for dso

2023-04-04T19:41:57+00:00

Later changes will add reference count checking for struct map, with
dso being the most frequently accessed variable. Add an accessor so
that the reference count check is only necessary in one place.

Additional changes:
 - add a dso variable to avoid repeated map__dso calls.
 - in builtin-mem.c dump_raw_samples, code only partially tested for
   dso == NULL. Make the possibility of NULL consistent.
 - in thread.c thread__memcpy fix use of spaces and use tabs.

Committer notes:

Did missing conversions on these files:

   tools/perf/arch/powerpc/util/skip-callchain-idx.c
   tools/perf/arch/powerpc/util/sym-handling.c
   tools/perf/ui/browsers/hists.c
   tools/perf/ui/gtk/annotate.c
   tools/perf/util/cs-etm.c
   tools/perf/util/thread.c
   tools/perf/util/unwind-libunwind-local.c
   tools/perf/util/unwind-libunwind.c

Signed-off-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Alexey Bayduraev 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: Andy Shevchenko 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: Dmitriy Vyukov 
Cc: Eric Dumazet 
Cc: German Gomez 
Cc: Hao Luo 
Cc: Ingo Molnar 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: John Garry 
Cc: Kajol Jain 
Cc: Kan Liang 
Cc: Leo Yan 
Cc: Madhavan Srinivasan 
Cc: Mark Rutland 
Cc: Masami Hiramatsu 
Cc: Miaoqian Lin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Riccardo Mancini 
Cc: Shunsuke Nakamura 
Cc: Song Liu 
Cc: Stephane Eranian 
Cc: Stephen Brennan 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Cc: Thomas Richter 
Cc: Yury Norov 
Link: https://lore.kernel.org/r/20230320212248.1175731-2-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

perf maps: Add functions to access maps

2023-04-04T18:45:38+00:00

Introduce functions to access struct maps. These functions reduce the
number of places reference counting is necessary. While tidying APIs do
some small const-ification, in particlar to unwind_libunwind_ops.

Committer notes:

Fixed up tools/perf/util/unwind-libunwind.c:

-               return ops->get_entries(cb, arg, thread, data, max_stack);
+               return ops->get_entries(cb, arg, thread, data, max_stack, best_effort);

Signed-off-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Alexey Bayduraev 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: Andy Shevchenko 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: Dmitriy Vyukov 
Cc: Eric Dumazet 
Cc: German Gomez 
Cc: Hao Luo 
Cc: Ingo Molnar 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: John Garry 
Cc: Kajol Jain 
Cc: Kan Liang 
Cc: Leo Yan 
Cc: Madhavan Srinivasan 
Cc: Mark Rutland 
Cc: Masami Hiramatsu 
Cc: Miaoqian Lin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Riccardo Mancini 
Cc: Shunsuke Nakamura 
Cc: Song Liu 
Cc: Stephane Eranian 
Cc: Stephen Brennan 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Cc: Thomas Richter 
Cc: Yury Norov 
Link: https://lore.kernel.org/r/20230320212248.1175731-2-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

perf maps: Remove rb_node from struct map

2023-04-04T17:06:27+00:00

struct map is reference counted, having it also be a node in an
red-black tree complicates the reference counting. Switch to having a
map_rb_node which is a red-block tree node but points at the reference
counted struct map. This reference is responsible for a single reference
count.

Committer notes:

Fixed up tools/perf/util/unwind-libunwind-local.c to use map_rb_node as
well.

Signed-off-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Alexey Bayduraev 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: Andy Shevchenko 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: Dmitriy Vyukov 
Cc: Eric Dumazet 
Cc: German Gomez 
Cc: Hao Luo 
Cc: Ingo Molnar 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: John Garry 
Cc: Kajol Jain 
Cc: Kan Liang 
Cc: Leo Yan 
Cc: Madhavan Srinivasan 
Cc: Mark Rutland 
Cc: Masami Hiramatsu 
Cc: Miaoqian Lin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Riccardo Mancini 
Cc: Shunsuke Nakamura 
Cc: Song Liu 
Cc: Stephane Eranian 
Cc: Stephen Brennan 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Cc: Thomas Richter 
Cc: Yury Norov 
Link: https://lore.kernel.org/r/20230320212248.1175731-2-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

perf top: Fix rare segfault in thread__comm_len()

2023-03-15T13:28:25+00:00

In thread__comm_len(),strlen() is called outside of the
thread->comm_lock critical section,which may cause a UAF
problems if comm__free() is called by the process_thread
concurrently.

backtrace of the core file is as follows:

    (gdb) bt
    #0  __strlen_evex () at ../sysdeps/x86_64/multiarch/strlen-evex.S:77
    #1  0x000055ad15d31de5 in thread__comm_len (thread=0x7f627d20e300) at util/thread.c:320
    #2  0x000055ad15d4fade in hists__calc_col_len (h=0x7f627d295940, hists=0x55ad1772bfe0)
        at util/hist.c:103
    #3  hists__calc_col_len (hists=0x55ad1772bfe0, h=0x7f627d295940) at util/hist.c:79
    #4  0x000055ad15d52c8c in output_resort (hists=hists@entry=0x55ad1772bfe0, prog=0x0,
        use_callchain=false, cb=cb@entry=0x0, cb_arg=0x0) at util/hist.c:1926
    #5  0x000055ad15d530a4 in evsel__output_resort_cb (evsel=evsel@entry=0x55ad1772bde0,
        prog=prog@entry=0x0, cb=cb@entry=0x0, cb_arg=cb_arg@entry=0x0) at util/hist.c:1945
    #6  0x000055ad15d53110 in evsel__output_resort (evsel=evsel@entry=0x55ad1772bde0,
        prog=prog@entry=0x0) at util/hist.c:1950
    #7  0x000055ad15c6ae9a in perf_top__resort_hists (t=t@entry=0x7ffcd9cbf4f0) at builtin-top.c:311
    #8  0x000055ad15c6cc6d in perf_top__print_sym_table (top=0x7ffcd9cbf4f0) at builtin-top.c:346
    #9  display_thread (arg=0x7ffcd9cbf4f0) at builtin-top.c:700
    #10 0x00007f6282fab4fa in start_thread (arg=) at pthread_create.c:443
    #11 0x00007f628302e200 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

The reason is that strlen() get a pointer to a memory that has been freed.

The string pointer is stored in the structure comm_str, which corresponds
to a rb_tree node,when the node is erased, the memory of the string is also freed.

In thread__comm_len(),it gets the pointer within the thread->comm_lock critical section,
but passed to strlen() outside of the thread->comm_lock critical section, and the perf
process_thread may called comm__free() concurrently, cause this segfault problem.

The process is as follows:

display_thread                                  process_thread
--------------                                  --------------

thread__comm_len
  -> thread__comm_str
       # held the comm read lock
    -> __thread__comm_str(thread)
       # release the comm read lock
                                                thread__delete
                                                     # held the comm write lock
                                                  -> comm__free
                                                    -> comm_str__put(comm->comm_str)
                                                      -> zfree(&cs->str)
                                                     # release the comm write lock
      # The memory of the string pointed
        to by comm has been free.
    -> thread->comm_len = strlen(comm);

This patch expand the critical section range of thread->comm_lock in thread__comm_len(),
to make strlen() called safe.

Signed-off-by: Wenyu Liu 
Acked-by: Namhyung Kim 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Christian Brauner 
Cc: Feilong Lin 
Cc: Hewenliang 
Cc: Ian Rogers 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Yunfeng Ye 
Link: https://lore.kernel.org/r/322bfb49-840b-f3b6-9ef1-f9ec3435b07e@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Add guest_cpu to hypervisor threads

2022-07-20T14:08:04+00:00

It is possible to know which guest machine was running at a point in time
based on the PID of the currently running host thread. That is, perf
identifies guest machines by the PID of the hypervisor.

To determine the guest CPU, put it on the hypervisor (QEMU) thread for
that VCPU.

This is done when processing the id_index which provides the necessary
information.

Signed-off-by: Adrian Hunter 
Cc: Andi Kleen 
Cc: Ian Rogers 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: kvm@vger.kernel.org
Link: https://lore.kernel.org/r/20220711093218.10967-13-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf callchain: Stitch LBR call stack

2020-04-18T12:05:01+00:00

In LBR call stack mode, the depth of reconstructed LBR call stack limits
to the number of LBR registers.

  For example, on skylake, the depth of reconstructed LBR call stack is
  always <= 32.

  # To display the perf.data header info, please use
  # --header/--header-only options.
  #
  #
  # Total Lost Samples: 0
  #
  # Samples: 6K of event 'cycles'
  # Event count (approx.): 6487119731
  #
  # Children      Self  Command          Shared Object       Symbol
  # ........  ........  ...............  ..................
  # ................................

    99.97%    99.97%  tchain_edit      tchain_edit        [.] f43
            |
             --99.64%--f11
                       f12
                       f13
                       f14
                       f15
                       f16
                       f17
                       f18
                       f19
                       f20
                       f21
                       f22
                       f23
                       f24
                       f25
                       f26
                       f27
                       f28
                       f29
                       f30
                       f31
                       f32
                       f33
                       f34
                       f35
                       f36
                       f37
                       f38
                       f39
                       f40
                       f41
                       f42
                       f43

For a call stack which is deeper than LBR limit, HW will overwrite the
LBR register with oldest branch. Only partial call stacks can be
reconstructed.

However, the overwritten LBRs may still be retrieved from previous
sample. At that moment, HW hasn't overwritten the LBR registers yet.
Perf tools can stitch those overwritten LBRs on current call stacks to
get a more complete call stack.

To determine if LBRs can be stitched, perf tools need to compare current
sample with previous sample.

- They should have identical LBR records (Same from, to and flags
  values, and the same physical index of LBR registers).

- The searching starts from the base-of-stack of current sample.

Once perf determines to stitch the previous LBRs, the corresponding LBR
cursor nodes will be copied to 'lists'.  The 'lists' is to track the LBR
cursor nodes which are going to be stitched.

When the stitching is over, the nodes will not be freed immediately.
They will be moved to 'free_lists'. Next stitching may reuse the space.
Both 'lists' and 'free_lists' will be freed when all samples are
processed.

Committer notes:

Fix the intel-pt.c initialization of the union with 'struct
branch_flags', that breaks the build with its unnamed union on older gcc
versions.

Uninline thread__free_stitch_list(), as it grew big and started dragging
includes to thread.h, so move it to thread.c where what it needs in
terms of headers are already there.

This fixes the build in several systems such as debian:experimental when
cross building to the MIPS32 architecture, i.e. in the other cases what
was needed was being included by sheer luck.

  In file included from builtin-sched.c:11:
  util/thread.h: In function 'thread__free_stitch_list':
  util/thread.h:169:3: error: implicit declaration of function 'free' [-Werror=implicit-function-declaration]
    169 |   free(pos);
        |   ^~~~
  util/thread.h:169:3: error: incompatible implicit declaration of built-in function 'free' [-Werror]
  util/thread.h:19:1: note: include '' or provide a declaration of 'free'
     18 | #include "callchain.h"
    +++ |+#include 
     19 |
  util/thread.h:174:3: error: incompatible implicit declaration of built-in function 'free' [-Werror]
    174 |   free(pos);
        |   ^~~~
  util/thread.h:174:3: note: include '' or provide a declaration of 'free'

Signed-off-by: Kan Liang 
Reviewed-by: Andi Kleen 
Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexey Budankov 
Cc: Mathieu Poirier 
Cc: Michael Ellerman 
Cc: Namhyung Kim 
Cc: Pavel Gerasimov 
Cc: Peter Zijlstra 
Cc: Ravi Bangoria 
Cc: Stephane Eranian 
Cc: Vitaly Slobodskoy 
Link: http://lore.kernel.org/lkml/20200319202517.23423-13-kan.liang@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf thread: Save previous sample for LBR stitching approach

2020-04-18T12:05:01+00:00

To retrieve the overwritten LBRs from previous sample for LBR stitching
approach, perf has to save the previous sample.

Only allocate the struct lbr_stitch once, when LBR stitching approach is
enabled and kernel supports hw_idx.

Signed-off-by: Kan Liang 
Reviewed-by: Andi Kleen 
Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexey Budankov 
Cc: Mathieu Poirier 
Cc: Michael Ellerman 
Cc: Namhyung Kim 
Cc: Pavel Gerasimov 
Cc: Peter Zijlstra 
Cc: Ravi Bangoria 
Cc: Stephane Eranian 
Cc: Vitaly Slobodskoy 
Link: http://lore.kernel.org/lkml/20200319202517.23423-11-kan.liang@linux.intel.com
[ Use zalloc()/zfree() for thread->lbr_stitch ]
Signed-off-by: Arnaldo Carvalho de Melo

perf thread: Add a knob for LBR stitch approach

2020-04-18T12:05:01+00:00

The LBR stitch approach should be disabled by default. Because

- The stitching approach base on LBR call stack technology. The known
  limitations of LBR call stack technology still apply to the approach,
  e.g. Exception handing such as setjmp/longjmp will have calls/returns
  not match.

- This approach is not foolproof. There can be cases where it creates
  incorrect call stacks from incorrect matches. There is no attempt to
  validate any matches in another way.

The 'lbr_stitch_enable' is used to indicate whether enable LBR stitch
approach, which is disabled by default. The following patch will
introduce a new option for each tools to enable the LBR stitch
approach.

Signed-off-by: Kan Liang 
Reviewed-by: Andi Kleen 
Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexey Budankov 
Cc: Mathieu Poirier 
Cc: Michael Ellerman 
Cc: Namhyung Kim 
Cc: Pavel Gerasimov 
Cc: Peter Zijlstra 
Cc: Ravi Bangoria 
Cc: Stephane Eranian 
Cc: Vitaly Slobodskoy 
Link: http://lore.kernel.org/lkml/20200319202517.23423-10-kan.liang@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf thread: Rename thread->mg to thread->maps

2019-11-26T14:07:46+00:00

One more step on the merge of 'struct maps' with 'struct map_groups'.

Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-69vcr8pubpym90skxhmbwhiw@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo