linux-kernel - Re: perf report does not resolve symbols on s390x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170712140412.GK27350@kernel.org>
Date:   Wed, 12 Jul 2017 11:04:12 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     Thomas-Mich Richter <tmricht@...ux.vnet.ibm.com>,
        "linux-perf-use." <linux-perf-users@...r.kernel.org>,
        Hendrik Brueckner <brueckner@...ux.vnet.ibm.com>,
        Zvonko Kosic <zvonko.kosic@...ibm.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andi Kleen <ak@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: perf report does not resolve symbols on s390x

Em Wed, Jul 12, 2017 at 08:40:57PM +1000, Michael Ellerman escreveu:
> Arnaldo Carvalho de Melo <acme@...nel.org> writes:
> 
> > Em Tue, Jul 11, 2017 at 04:38:28PM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Tue, Jul 11, 2017 at 04:03:04PM -0300, Arnaldo Carvalho de Melo escreveu:
> >> > Em Fri, Jul 07, 2017 at 02:17:25PM +0200, Thomas-Mich Richter escreveu:
> >> > > On 07/06/2017 02:35 PM, Thomas-Mich Richter wrote:
> >> > > It determines the kernel starts at address 1<<63 and loads the kernel address mapping.
> >> > > On s390x
> >> > > - The kernel starts at 0x0 (value of map->start) and thus all checks in function 
> >> > >   thread__find_addr_map() fail and no symbol is found for the specified addresses
> >> > >   because the kernel starts at 0x8000000000000000. Which is wrong the kernel start at 0x0.
> >
> >> > Hi Thomas, really nice debugging session!
> >
> >> > I'm trying the one-liner below, Adrian, can you please check this and
> >> > provide an ack? I think that that comment about the address that it will
> >> > default when map__load() fails needs rewriting in light of Thomas
> >> > comments about other arches (see further below)?
> >
> >> > I did a quick check of machine->kernel_start usage in Intel PT and since
> >> > on x86 that assumption about partitioning the address space holds, no
> >> > problem should be introduced by the one-liner fix, right?
> >  
> >> Argh, this is also broken:
> >  
> >> static inline bool machine__kernel_ip(struct machine *machine, u64 ip)
> >> {
> >>         u64 kernel_start = machine__kernel_start(machine);
> >> 
> >>         return ip >= kernel_start;
> >> }
> >> 
> >> We can't judge if a address is in the kernel like that :-\
> >
> > So, this is used by:
> >
> > [acme@...et linux]$ find tools/ -name "*.[ch]" | xargs grep -w machine__kernel_ip
> > tools/perf/builtin-script.c:	kernel = machine__kernel_ip(machine, start);
> > tools/perf/builtin-script.c:	if (kernel != machine__kernel_ip(machine, end)) {
> >
> > That is just for "brstackinsn", would that make sense for Sparc, S/390?
> >
> > tools/perf/util/intel-bts.c:	if (machine__kernel_ip(machine, ip))
> > tools/perf/util/intel-bts.c:		if (!machine__kernel_ip(btsq->bts->machine, branch->from) &&
> > tools/perf/util/intel-bts.c:		    machine__kernel_ip(btsq->bts->machine, branch->to) &&
> >
> > Intel specific stuff, so should be ok.
> >
> > tools/perf/util/event.c:		    machine__kernel_ip(machine, al->addr)) {
> >
> > For this last one, that affects all arches, I think we can just remove
> > this check and look at the kernel when not finding it anywhere else?
> >
> > diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> > index dc5c3bb69d73..8e435baaae6a 100644
> > --- a/tools/perf/util/event.c
> > +++ b/tools/perf/util/event.c
> > @@ -1432,8 +1432,7 @@ void thread__find_addr_map(struct thread *thread, u8 cpumode,
> >  		 * in the whole kernel symbol list.
> >  		 */
> >  		if (cpumode == PERF_RECORD_MISC_USER && machine &&
> > -		    mg != &machine->kmaps &&
> > -		    machine__kernel_ip(machine, al->addr)) {
> > +		    mg != &machine->kmaps) {
> >  			mg = &machine->kmaps;
> >  			load_map = true;
> >  			goto try_again;
> 
> Am I reading this right? We have a sample that claims to be in
> userspace, but was not found in any symbol map, so we try looking for it
> in the kernel map.
> 
> And the change is that previously we checked if the address was >= (1 << 63),
> whereas after we don't bother.
> 
> Seems harmless™.

Thanks, will take that as an Acked-by:, ok?

 
> cheers