[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150330111819.0193c04e@thinkpad-w530>
Date: Mon, 30 Mar 2015 11:18:19 +0200
From: David Hildenbrand <dahi@...ux.vnet.ibm.com>
To: Jiri Olsa <jolsa@...hat.com>
Cc: linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl,
paulus@...ba.org, mingo@...hat.com, acme@...nel.org,
acme@...hat.com, jolsa@...nel.org, kan.liang@...el.com,
namhyung@...nel.org, adrian.hunter@...el.com, ak@...ux.intel.com,
brueckner@...ux.vnet.ibm.com, schwidefsky@...ibm.com
Subject: Re: [PATCH v2] perf callchain: fix kernel symbol resolution by
remembering the cpumode
> On Mon, Mar 30, 2015 at 10:11:00AM +0200, David Hildenbrand wrote:
> > Commit 2e77784bb7d8 ("perf callchain: Move cpumode resolve code to
> > add_callchain_ip") promised "No change in behavior.".
> >
> > As this commit breaks callchains on s390x (symbols not getting resolved,
>
> I think it's a generic problem not just s390x
>
> the x86 archs were safe due to the (al->map == NULL) fallback
> in thread__find_addr_map, where we rerun the lookup for kernel
> maps.. I need to rethink this check :-\
>
> perhaps s390x did not match the machine__kernel_ip condition?
Most probably yes, in contrast to other archs, we can't really decide based on
the address if it belongs to user or kernel space. So we need the context.
>
>
> > observed when profiling the kernel), this statement is wrong. The cpumode
> > must be kept when iterating over all ips, otherwise the default
> > (PERF_RECORD_MISC_USER) will be used by error.
>
> anyway
>
> Acked-by: Jiri Olsa <jolsa@...nel.org>
>
>
Thanks!
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists