Message-Id: <20220128203950.3371061-1-namhyung@kernel.org>
Date:   Fri, 28 Jan 2022 12:39:47 -0800
From:   Namhyung Kim <namhyung@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Ian Rogers <irogers@...gle.com>
Subject: [PATCH 0/3] Handle chroot tasks properly (v1)

Hello,

I found that perf tools don't work well with tasks in a chroot.  The
filenames in MMAP record are from the root directory of the task so
it's different than what it sees from outside.

I've tested it with a simple program (myprog - statically built) which
just consumes cpu cycles in a loop for a while (default 1 sec, can by
overridden by a command-line argument).

  # cd $HOME
  # mkdir -p myroot/bin
  # cp myprog myroot/bin

  # perf record chroot myroot myprog
  # perf report -D | grep MMAP | grep myprog
  2084916774977911 0xa2e4 [0x70]: PERF_RECORD_MMAP2 3363818/3363818: \
  [0x401000(0x80000) @ 0x1000 fe:01 4346398 2543719070]: r-xp /bin/myprog

So it's reported as /bin/myprog and then it's unable to symbolize the
samples.  It seems hard to fix it for the above use case as the record
ended after the task exited.  It cannot know the root directory of the
task anymore.  But we can fix it for real-time use cases like perf top
or pipe-mode at least.

I tested it again with the following command.

  # perf record -o- chroot myroot myprog | perf report -i-
  ...
  #
  # Overhead  Command  Shared Object      Symbol                          
  # ........  .......  .................  ................................
  #
      46.02%  myprog   myprog             [.] 0x000000000000178a
      36.71%  myprog   myprog             [.] 0x0000000000001792
      17.12%  myprog   myprog             [.] 0x000000000000178e
       0.05%  myprog   myprog             [.] 0x0000000000001796
       0.05%  chroot   ld-2.33.so         [.] intel_check_word.constprop.0

The symbols are not resolved because it failed to load the symbol
table as it didn't find the file in the given path.

So I modified the code to try a new name prepended with the task's
root directory when it's not "/".  With this change, I can see the
symbols of myprog.  In fact, it depends on timing if perf report hits
the file before the task is gone.  Increasing the loop time to 3 sec
helped it to get symbols reliably.

  # perf record -o- chroot myroot myprog 3 | perf report -i-
  ...
  #
  # Overhead  Command  Shared Object      Symbol                       
  # ........  .......  .................  .............................
  #
      99.83%  myprog   myprog             [.] loop
       0.04%  chroot   [kernel.kallsyms]  [k] fxregs_fixup
       0.04%  chroot   [kernel.kallsyms]  [k] rsm_load_seg_32
       0.03%  chroot   [kernel.kallsyms]  [k] show_cpuinfo_cur_freq
       0.01%  myprog   [kernel.kallsyms]  [k] alarmtimer_fired


I also found that perf inject and perf annotate need the similar changes.

You can get it from 'perf/dso-chroot-v1' branch at

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git


Thanks,
Namhyung


Namhyung Kim (3):
  perf tools: Try chroot'ed filename when opening dso/symbol
  perf inject: Try chroot directory when reading build-id
  perf annotate: Try chroot filename for objdump

 tools/perf/builtin-inject.c | 10 ++++++++++
 tools/perf/util/annotate.c  | 11 +++++++++++
 tools/perf/util/dso.c       | 15 +++++++++++++--
 tools/perf/util/dsos.c      | 13 +++++++++++++
 tools/perf/util/symbol.c    | 10 ++++++++++
 tools/perf/util/util.c      | 31 +++++++++++++++++++++++++++++++
 tools/perf/util/util.h      |  2 ++
 7 files changed, 90 insertions(+), 2 deletions(-)


base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07
-- 
2.35.0.rc2.247.g8bbb082509-goog

Powered by blists - more mailing lists