Re: [PATCH 0/4] Handle chroot tasks properly (v2)

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Tue, Feb 01, 2022 at 11:08:24PM -0800, Namhyung Kim escreveu:
> 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.
> 
>  * changes in v2)
>   - add Jiri's Acked-by
>   - split stderr setup for objdump

Applied 1/4 to perf/urgent, its already upstream.

The others are bit big for this time, so I've added it to perf/core.

Thanks,

- Arnaldo
 
> 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-v2' branch at
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> 
> 
> Thanks,
> Namhyung
> 
> 
> Namhyung Kim (4):
>   perf annotate: Set error stream of objdump process for TUI
>   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

-- 

- Arnaldo