* [PATCH 1/3] perf tools: Try chroot'ed filename when opening dso/symbol
2022-01-28 20:39 [PATCH 0/3] Handle chroot tasks properly (v1) Namhyung Kim
@ 2022-01-28 20:39 ` Namhyung Kim
2022-01-28 20:39 ` [PATCH 2/3] perf inject: Try chroot directory when reading build-id Namhyung Kim
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Namhyung Kim @ 2022-01-28 20:39 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa
Cc: Ingo Molnar, Peter Zijlstra, LKML, Andi Kleen, Ian Rogers
Currently it doesn't handle tasks in chroot properly. As filenames in
MMAP records base on their root directory, it's different than what
perf tool can see from outside.
Add filename_with_chroot() helper to deal with those cases. The
function returns a new filename only if it's in a different root
directory. Since it needs to access /proc for the process, it only
works until the task exits.
With this change, I can see symbols in my program like below.
# 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
...
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
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 ++
5 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 9cc8a1772b4b..5ac13958d1bd 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -508,8 +508,19 @@ static int __open_dso(struct dso *dso, struct machine *machine)
root_dir, name, PATH_MAX))
goto out;
- if (!is_regular_file(name))
- goto out;
+ if (!is_regular_file(name)) {
+ char *new_name;
+
+ if (errno != ENOENT || dso->nsinfo == NULL)
+ goto out;
+
+ new_name = filename_with_chroot(dso->nsinfo->pid, name);
+ if (!new_name)
+ goto out;
+
+ free(name);
+ name = new_name;
+ }
if (dso__needs_decompress(dso)) {
char newpath[KMOD_DECOMP_LEN];
diff --git a/tools/perf/util/dsos.c b/tools/perf/util/dsos.c
index 183a81d5b2f9..b97366f77bbf 100644
--- a/tools/perf/util/dsos.c
+++ b/tools/perf/util/dsos.c
@@ -2,12 +2,15 @@
#include "debug.h"
#include "dsos.h"
#include "dso.h"
+#include "util.h"
#include "vdso.h"
#include "namespaces.h"
+#include <errno.h>
#include <libgen.h>
#include <stdlib.h>
#include <string.h>
#include <symbol.h> // filename__read_build_id
+#include <unistd.h>
static int __dso_id__cmp(struct dso_id *a, struct dso_id *b)
{
@@ -76,6 +79,16 @@ bool __dsos__read_build_ids(struct list_head *head, bool with_hits)
if (filename__read_build_id(pos->long_name, &pos->bid) > 0) {
have_build_id = true;
pos->has_build_id = true;
+ } else if (errno == ENOENT && pos->nsinfo) {
+ char *new_name = filename_with_chroot(pos->nsinfo->pid,
+ pos->long_name);
+
+ if (new_name && filename__read_build_id(new_name,
+ &pos->bid) > 0) {
+ have_build_id = true;
+ pos->has_build_id = true;
+ }
+ free(new_name);
}
nsinfo__mountns_exit(&nsc);
}
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index b2ed3140a1fa..34302c61d36b 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1864,6 +1864,16 @@ int dso__load(struct dso *dso, struct map *map)
nsinfo__mountns_exit(&nsc);
is_reg = is_regular_file(name);
+ if (!is_reg && errno == ENOENT && dso->nsinfo) {
+ char *new_name = filename_with_chroot(dso->nsinfo->pid,
+ name);
+ if (new_name) {
+ is_reg = is_regular_file(new_name);
+ strlcpy(name, new_name, PATH_MAX);
+ free(new_name);
+ }
+ }
+
#ifdef HAVE_LIBBFD_SUPPORT
if (is_reg)
bfdrc = dso__load_bfd_symbols(dso, name);
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index fb4f6616b5fa..f8571a66d063 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -431,3 +431,34 @@ void perf_debuginfod_setup(struct perf_debuginfod *di)
pr_debug("DEBUGINFOD_URLS=%s\n", getenv("DEBUGINFOD_URLS"));
}
+
+/*
+ * Return a new filename prepended with task's root directory if it's in
+ * a chroot. Callers should free the returned string.
+ */
+char *filename_with_chroot(int pid, const char *filename)
+{
+ char buf[PATH_MAX];
+ char proc_root[32];
+ char *new_name = NULL;
+ int ret;
+
+ scnprintf(proc_root, sizeof(proc_root), "/proc/%d/root", pid);
+ ret = readlink(proc_root, buf, sizeof(buf) - 1);
+ if (ret <= 0)
+ return NULL;
+
+ /* readlink(2) does not append a null byte to buf */
+ buf[ret] = '\0';
+
+ if (!strcmp(buf, "/"))
+ return NULL;
+
+ if (strstr(buf, "(deleted)"))
+ return NULL;
+
+ if (asprintf(&new_name, "%s/%s", buf, filename) < 0)
+ return NULL;
+
+ return new_name;
+}
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 7b625cbd2dd8..0f78f1e7782d 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -77,4 +77,6 @@ struct perf_debuginfod {
bool set;
};
void perf_debuginfod_setup(struct perf_debuginfod *di);
+
+char *filename_with_chroot(int pid, const char *filename);
#endif /* GIT_COMPAT_UTIL_H */
--
2.35.0.rc2.247.g8bbb082509-goog
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/3] perf inject: Try chroot directory when reading build-id
2022-01-28 20:39 [PATCH 0/3] Handle chroot tasks properly (v1) Namhyung Kim
2022-01-28 20:39 ` [PATCH 1/3] perf tools: Try chroot'ed filename when opening dso/symbol Namhyung Kim
@ 2022-01-28 20:39 ` Namhyung Kim
2022-01-28 20:39 ` [PATCH 3/3] perf annotate: Try chroot filename for objdump Namhyung Kim
2022-02-01 1:16 ` [PATCH 0/3] Handle chroot tasks properly (v1) Andi Kleen
3 siblings, 0 replies; 10+ messages in thread
From: Namhyung Kim @ 2022-01-28 20:39 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa
Cc: Ingo Molnar, Peter Zijlstra, LKML, Andi Kleen, Ian Rogers
When reading build-id from a DSO, it should consider if it's from a
chroot task. In that case, the path is different so it needs to
prepend the root directory to access the file correctly.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
tools/perf/builtin-inject.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index fbf43a454cba..3be581abbdb6 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -25,6 +25,7 @@
#include "util/synthetic-events.h"
#include "util/thread.h"
#include "util/namespaces.h"
+#include "util/util.h"
#include <linux/err.h>
#include <subcmd/parse-options.h>
@@ -550,6 +551,15 @@ static int dso__read_build_id(struct dso *dso)
nsinfo__mountns_enter(dso->nsinfo, &nsc);
if (filename__read_build_id(dso->long_name, &dso->bid) > 0)
dso->has_build_id = true;
+ else if (dso->nsinfo) {
+ char *new_name;
+
+ new_name = filename_with_chroot(dso->nsinfo->pid,
+ dso->long_name);
+ if (new_name && filename__read_build_id(new_name, &dso->bid) > 0)
+ dso->has_build_id = true;
+ free(new_name);
+ }
nsinfo__mountns_exit(&nsc);
return dso->has_build_id ? 0 : -1;
--
2.35.0.rc2.247.g8bbb082509-goog
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 3/3] perf annotate: Try chroot filename for objdump
2022-01-28 20:39 [PATCH 0/3] Handle chroot tasks properly (v1) Namhyung Kim
2022-01-28 20:39 ` [PATCH 1/3] perf tools: Try chroot'ed filename when opening dso/symbol Namhyung Kim
2022-01-28 20:39 ` [PATCH 2/3] perf inject: Try chroot directory when reading build-id Namhyung Kim
@ 2022-01-28 20:39 ` Namhyung Kim
2022-01-31 19:23 ` Jiri Olsa
2022-02-01 1:16 ` [PATCH 0/3] Handle chroot tasks properly (v1) Andi Kleen
3 siblings, 1 reply; 10+ messages in thread
From: Namhyung Kim @ 2022-01-28 20:39 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa
Cc: Ingo Molnar, Peter Zijlstra, LKML, Andi Kleen, Ian Rogers
Likewise, it should use a proper name in case the task runs under
chroot. The child_process.err was needed to set to -1 to show error
messages properly in TUI.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
tools/perf/util/annotate.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 01900689dc00..e4c641b240df 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -33,6 +33,7 @@
#include "string2.h"
#include "util/event.h"
#include "arch/common.h"
+#include "namespaces.h"
#include <regex.h>
#include <pthread.h>
#include <linux/bitops.h>
@@ -1696,6 +1697,15 @@ static int dso__disassemble_filename(struct dso *dso, char *filename, size_t fil
* DSO is the same as when 'perf record' ran.
*/
__symbol__join_symfs(filename, filename_size, dso->long_name);
+
+ if (access(filename, R_OK) && errno == ENOENT && dso->nsinfo) {
+ char *new_name = filename_with_chroot(dso->nsinfo->pid,
+ filename);
+ if (new_name) {
+ strlcpy(filename, new_name, filename_size);
+ free(new_name);
+ }
+ }
}
free(build_id_path);
@@ -2036,6 +2046,7 @@ static int symbol__disassemble(struct symbol *sym, struct annotate_args *args)
memset(&objdump_process, 0, sizeof(objdump_process));
objdump_process.argv = objdump_argv;
objdump_process.out = -1;
+ objdump_process.err = -1;
if (start_command(&objdump_process)) {
pr_err("Failure starting to run %s\n", command);
err = -1;
--
2.35.0.rc2.247.g8bbb082509-goog
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] perf annotate: Try chroot filename for objdump
2022-01-28 20:39 ` [PATCH 3/3] perf annotate: Try chroot filename for objdump Namhyung Kim
@ 2022-01-31 19:23 ` Jiri Olsa
2022-02-01 19:54 ` Namhyung Kim
0 siblings, 1 reply; 10+ messages in thread
From: Jiri Olsa @ 2022-01-31 19:23 UTC (permalink / raw)
To: Namhyung Kim
Cc: Arnaldo Carvalho de Melo, Ingo Molnar, Peter Zijlstra, LKML,
Andi Kleen, Ian Rogers
On Fri, Jan 28, 2022 at 12:39:50PM -0800, Namhyung Kim wrote:
> Likewise, it should use a proper name in case the task runs under
> chroot. The child_process.err was needed to set to -1 to show error
> messages properly in TUI.
>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> ---
> tools/perf/util/annotate.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> index 01900689dc00..e4c641b240df 100644
> --- a/tools/perf/util/annotate.c
> +++ b/tools/perf/util/annotate.c
> @@ -33,6 +33,7 @@
> #include "string2.h"
> #include "util/event.h"
> #include "arch/common.h"
> +#include "namespaces.h"
> #include <regex.h>
> #include <pthread.h>
> #include <linux/bitops.h>
> @@ -1696,6 +1697,15 @@ static int dso__disassemble_filename(struct dso *dso, char *filename, size_t fil
> * DSO is the same as when 'perf record' ran.
> */
> __symbol__join_symfs(filename, filename_size, dso->long_name);
> +
> + if (access(filename, R_OK) && errno == ENOENT && dso->nsinfo) {
> + char *new_name = filename_with_chroot(dso->nsinfo->pid,
> + filename);
> + if (new_name) {
> + strlcpy(filename, new_name, filename_size);
> + free(new_name);
> + }
> + }
> }
>
> free(build_id_path);
> @@ -2036,6 +2046,7 @@ static int symbol__disassemble(struct symbol *sym, struct annotate_args *args)
> memset(&objdump_process, 0, sizeof(objdump_process));
> objdump_process.argv = objdump_argv;
> objdump_process.out = -1;
> + objdump_process.err = -1;
is this unrelated fix?
otherwise the whole patchset looks good to me
I guess we'd need to add something like PERF_RECORD_CHROOT to
handle and instrument sys_chroot to handle this completely?
Acked-by: Jiri Olsa <jolsa@kernel.org>
thanks,
jirka
> if (start_command(&objdump_process)) {
> pr_err("Failure starting to run %s\n", command);
> err = -1;
> --
> 2.35.0.rc2.247.g8bbb082509-goog
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] perf annotate: Try chroot filename for objdump
2022-01-31 19:23 ` Jiri Olsa
@ 2022-02-01 19:54 ` Namhyung Kim
2022-02-02 0:06 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 10+ messages in thread
From: Namhyung Kim @ 2022-02-01 19:54 UTC (permalink / raw)
To: Jiri Olsa
Cc: Arnaldo Carvalho de Melo, Ingo Molnar, Peter Zijlstra, LKML,
Andi Kleen, Ian Rogers
Hi Jiri,
On Mon, Jan 31, 2022 at 11:23 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Fri, Jan 28, 2022 at 12:39:50PM -0800, Namhyung Kim wrote:
> > Likewise, it should use a proper name in case the task runs under
> > chroot. The child_process.err was needed to set to -1 to show error
> > messages properly in TUI.
> >
> > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > ---
> > tools/perf/util/annotate.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> > index 01900689dc00..e4c641b240df 100644
> > --- a/tools/perf/util/annotate.c
> > +++ b/tools/perf/util/annotate.c
> > @@ -33,6 +33,7 @@
> > #include "string2.h"
> > #include "util/event.h"
> > #include "arch/common.h"
> > +#include "namespaces.h"
> > #include <regex.h>
> > #include <pthread.h>
> > #include <linux/bitops.h>
> > @@ -1696,6 +1697,15 @@ static int dso__disassemble_filename(struct dso *dso, char *filename, size_t fil
> > * DSO is the same as when 'perf record' ran.
> > */
> > __symbol__join_symfs(filename, filename_size, dso->long_name);
> > +
> > + if (access(filename, R_OK) && errno == ENOENT && dso->nsinfo) {
> > + char *new_name = filename_with_chroot(dso->nsinfo->pid,
> > + filename);
> > + if (new_name) {
> > + strlcpy(filename, new_name, filename_size);
> > + free(new_name);
> > + }
> > + }
> > }
> >
> > free(build_id_path);
> > @@ -2036,6 +2046,7 @@ static int symbol__disassemble(struct symbol *sym, struct annotate_args *args)
> > memset(&objdump_process, 0, sizeof(objdump_process));
> > objdump_process.argv = objdump_argv;
> > objdump_process.out = -1;
> > + objdump_process.err = -1;
>
> is this unrelated fix?
Right, it's unrelated. Maybe I can split it if Arnaldo wants.
>
> otherwise the whole patchset looks good to me
>
> I guess we'd need to add something like PERF_RECORD_CHROOT to
> handle and instrument sys_chroot to handle this completely?
Are you talking about an env variable? Maybe we can track
chroot syscall. But it needs to be task-specific rather than a
global setup.
As it hasn't been an issue so far, I think it's ok to have it as
a fallback right now.
>
> Acked-by: Jiri Olsa <jolsa@kernel.org>
Thanks for your review!
Namhyung
>
> > if (start_command(&objdump_process)) {
> > pr_err("Failure starting to run %s\n", command);
> > err = -1;
> > --
> > 2.35.0.rc2.247.g8bbb082509-goog
> >
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] perf annotate: Try chroot filename for objdump
2022-02-01 19:54 ` Namhyung Kim
@ 2022-02-02 0:06 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 10+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-02-02 0:06 UTC (permalink / raw)
To: Namhyung Kim
Cc: Jiri Olsa, Ingo Molnar, Peter Zijlstra, LKML, Andi Kleen, Ian Rogers
Em Tue, Feb 01, 2022 at 11:54:14AM -0800, Namhyung Kim escreveu:
> Hi Jiri,
>
> On Mon, Jan 31, 2022 at 11:23 AM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Fri, Jan 28, 2022 at 12:39:50PM -0800, Namhyung Kim wrote:
> > > Likewise, it should use a proper name in case the task runs under
> > > chroot. The child_process.err was needed to set to -1 to show error
> > > messages properly in TUI.
> > >
> > > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > > ---
> > > tools/perf/util/annotate.c | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> > > index 01900689dc00..e4c641b240df 100644
> > > --- a/tools/perf/util/annotate.c
> > > +++ b/tools/perf/util/annotate.c
> > > @@ -33,6 +33,7 @@
> > > #include "string2.h"
> > > #include "util/event.h"
> > > #include "arch/common.h"
> > > +#include "namespaces.h"
> > > #include <regex.h>
> > > #include <pthread.h>
> > > #include <linux/bitops.h>
> > > @@ -1696,6 +1697,15 @@ static int dso__disassemble_filename(struct dso *dso, char *filename, size_t fil
> > > * DSO is the same as when 'perf record' ran.
> > > */
> > > __symbol__join_symfs(filename, filename_size, dso->long_name);
> > > +
> > > + if (access(filename, R_OK) && errno == ENOENT && dso->nsinfo) {
> > > + char *new_name = filename_with_chroot(dso->nsinfo->pid,
> > > + filename);
> > > + if (new_name) {
> > > + strlcpy(filename, new_name, filename_size);
> > > + free(new_name);
> > > + }
> > > + }
> > > }
> > >
> > > free(build_id_path);
> > > @@ -2036,6 +2046,7 @@ static int symbol__disassemble(struct symbol *sym, struct annotate_args *args)
> > > memset(&objdump_process, 0, sizeof(objdump_process));
> > > objdump_process.argv = objdump_argv;
> > > objdump_process.out = -1;
> > > + objdump_process.err = -1;
> >
> > is this unrelated fix?
>
> Right, it's unrelated. Maybe I can split it if Arnaldo wants.
Yes, please split.
> >
> > otherwise the whole patchset looks good to me
> >
> > I guess we'd need to add something like PERF_RECORD_CHROOT to
> > handle and instrument sys_chroot to handle this completely?
>
> Are you talking about an env variable? Maybe we can track
> chroot syscall. But it needs to be task-specific rather than a
> global setup.
>
> As it hasn't been an issue so far, I think it's ok to have it as
> a fallback right now.
>
> >
> > Acked-by: Jiri Olsa <jolsa@kernel.org>
>
> Thanks for your review!
Indeed, thank you guys!
> Namhyung
>
>
> >
> > > if (start_command(&objdump_process)) {
> > > pr_err("Failure starting to run %s\n", command);
> > > err = -1;
> > > --
> > > 2.35.0.rc2.247.g8bbb082509-goog
> > >
> >
--
- Arnaldo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/3] Handle chroot tasks properly (v1)
2022-01-28 20:39 [PATCH 0/3] Handle chroot tasks properly (v1) Namhyung Kim
` (2 preceding siblings ...)
2022-01-28 20:39 ` [PATCH 3/3] perf annotate: Try chroot filename for objdump Namhyung Kim
@ 2022-02-01 1:16 ` Andi Kleen
2022-02-01 20:01 ` Namhyung Kim
3 siblings, 1 reply; 10+ messages in thread
From: Andi Kleen @ 2022-02-01 1:16 UTC (permalink / raw)
To: Namhyung Kim, Arnaldo Carvalho de Melo, Jiri Olsa
Cc: Ingo Molnar, Peter Zijlstra, LKML, Ian Rogers
On 1/28/2022 12:39 PM, Namhyung Kim wrote:
> 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.
While that's a real problem, and for chroot it can be fixed, it's much
more complicated for the more complex container namespace case with
custom mounts, including loop back, etc.
It seems it really need some kind of agent to handle all cases. For
example the agent could understand container metadata formats and then
do the right thing.
-Andi
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/3] Handle chroot tasks properly (v1)
2022-02-01 1:16 ` [PATCH 0/3] Handle chroot tasks properly (v1) Andi Kleen
@ 2022-02-01 20:01 ` Namhyung Kim
2022-02-02 0:11 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 10+ messages in thread
From: Namhyung Kim @ 2022-02-01 20:01 UTC (permalink / raw)
To: Andi Kleen
Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Ingo Molnar, Peter Zijlstra,
LKML, Ian Rogers
Hi Andi,
On Mon, Jan 31, 2022 at 5:16 PM Andi Kleen <ak@linux.intel.com> wrote:
>
>
> On 1/28/2022 12:39 PM, Namhyung Kim wrote:
> > 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.
>
>
> While that's a real problem, and for chroot it can be fixed, it's much
> more complicated for the more complex container namespace case with
> custom mounts, including loop back, etc.
Probably. Note that perf tool can handle namespaces (to some extent)
but missed chroot support. I have a bug report because of this issue.
Let's fix the simple case first.
>
> It seems it really need some kind of agent to handle all cases. For
> example the agent could understand container metadata formats and then
> do the right thing.
Sounds like a good idea for a long term solution.
Thanks,
Namhyung
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/3] Handle chroot tasks properly (v1)
2022-02-01 20:01 ` Namhyung Kim
@ 2022-02-02 0:11 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 10+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-02-02 0:11 UTC (permalink / raw)
To: Namhyung Kim
Cc: Andi Kleen, Jiri Olsa, Ingo Molnar, Peter Zijlstra, LKML, Ian Rogers
Em Tue, Feb 01, 2022 at 12:01:49PM -0800, Namhyung Kim escreveu:
> On Mon, Jan 31, 2022 at 5:16 PM Andi Kleen <ak@linux.intel.com> wrote:
> > On 1/28/2022 12:39 PM, Namhyung Kim wrote:
> > > 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.
> > While that's a real problem, and for chroot it can be fixed, it's much
> > more complicated for the more complex container namespace case with
> > custom mounts, including loop back, etc.
> Probably. Note that perf tool can handle namespaces (to some extent)
> but missed chroot support. I have a bug report because of this issue.
> Let's fix the simple case first.
> > It seems it really need some kind of agent to handle all cases. For
> > example the agent could understand container metadata formats and then
> > do the right thing.
>
> Sounds like a good idea for a long term solution.
I think build ids are the way to go and would be really happy to have
arguments against it to be properly spelled out so we can harvest
documentation.
Its really difficult to associate a mmap to a backing storage, its race
prone, so having something that uniquely identifies the contents at the
time of mmap placement hugely desirable.
We seem to have that in most cases, and there is discussion about what
to do to the cases where parsing the ELF headers when that area is not
in memory, so there is hope that the buildid for an exec VMA will be
always available.
- Arnaldo
^ permalink raw reply [flat|nested] 10+ messages in thread