From: Jiri Olsa <jolsa@redhat.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: acme@kernel.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@redhat.com>,
Namhyung Kim <namhyung@kernel.org>,
Kan Liang <kan.liang@intel.com>, Andi Kleen <ak@linux.intel.com>,
linux-kernel@vger.kernel.org, Michael Petlan <mpetlan@redhat.com>
Subject: [PATCH] perf tools: Fix endless loop in dso__split_kallsyms_for_kcore
Date: Mon, 26 Oct 2015 14:51:30 +0100 [thread overview]
Message-ID: <20151026135130.GA26003@krava.brq.redhat.com> (raw)
In-Reply-To: <562E2919.5000601@intel.com>
On Mon, Oct 26, 2015 at 03:22:33PM +0200, Adrian Hunter wrote:
> On 26/10/15 15:01, Jiri Olsa wrote:
> > hi,
> > I'm getting stuck buildid-list command on s390
> >
> > seems like the kcore code gets stuck with inseting
> > into rbtree while iterating it..
> >
> > I was able to fix it with patch below, bu I'm not sure it's the
> > correct fix because the kcore maps magic is beyond me so far ;-)
> >
> > please check attached backtrace and patch
>
> Your fix looks correct to me.
great, attached patch with changelog.. please
feel free to add more detail or correct it
thanks,
jirka
---
Currently we split symbols based on the map comparison,
but symbols are stored within dso objects and maps could
point into same dso objects (kernel maps).
Hence we could end up changing rbtree we are currently
iterating and mess it up. It's easily reproduced on
s390x by running:
$ perf record -a -- sleep 3
$ perf buildid-list -i perf.data --with-hits
The fix is to compare dso objects instead.
Reported-by: Michael Petlan <mpetlan@redhat.com>
Link: http://lkml.kernel.org/n/tip-p9ge2nvme7u5s21j0sn987wd@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/perf/util/symbol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e7bf0c46918d..b0d2fb272f7e 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -680,7 +680,7 @@ static int dso__split_kallsyms_for_kcore(struct dso *dso, struct map *map,
pos->start -= curr_map->start - curr_map->pgoff;
if (pos->end)
pos->end -= curr_map->start - curr_map->pgoff;
- if (curr_map != map) {
+ if (curr_map->dso != map->dso) {
rb_erase_init(&pos->rb_node, root);
symbols__insert(
&curr_map->dso->symbols[curr_map->type],
--
2.4.3
next prev parent reply other threads:[~2015-10-26 13:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-26 13:01 [BUG] reporting stuck on s390 " Jiri Olsa
2015-10-26 13:22 ` Adrian Hunter
2015-10-26 13:51 ` Jiri Olsa [this message]
2015-10-29 9:42 ` [tip:perf/core] perf symbols: Fix endless loop " tip-bot for Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151026135130.GA26003@krava.brq.redhat.com \
--to=jolsa@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mpetlan@redhat.com \
--cc=namhyung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®