linux-kernel - Re: [PATCH 2/2] perf tools: Skip read of kernel maps once it failed

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] [day] [month] [year] [list]

Message-ID: <20180130112154.GA29098@krava>
Date:   Tue, 30 Jan 2018 12:21:54 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        David Ahern <dsahern@...il.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>, kernel-team@....com
Subject: Re: [PATCH 2/2] perf tools: Skip read of kernel maps once it failed

On Fri, Jan 26, 2018 at 03:48:30PM +0900, Namhyung Kim wrote:
> On Fri, Jan 19, 2018 at 05:11:03PM +0100, Jiri Olsa wrote:
> > Current perf report is real slow on newer kernels,
> > with following commit:
> >   c0f3ea158939 ("stop using '%pK' for /proc/kallsyms pointer values")
> > 
> > which prevent pointers in /proc/kallsyms, in case
> > kernel.perf_event_paranoid=2.
> > 
> > That makes perf to fail in finding kernel map details,
> > and keep parsing it again for every kernel sample.
> > 
> > Adding and setting a new machine::vmlinux_maps_failed
> > flag after first failed parsing attempt and using it
> > to prevent new pointless parsing.
> 
> Hmm.. is it because it's called from machine__resolve() right?
> 
> 	/*
> 	 * Have we already created the kernel maps for this machine?
> 	 *
> 	 * This should have happened earlier, when we processed the kernel MMAP
> 	 * events, but for older perf.data files there was no such thing, so do
> 	 * it now.
> 	 */
> 
> It seems that it's only to be compatible with ancient versions.
> 
> Do we still need it?  I guess they are recorded many years ago (with
> the ancient version) so using addresses of current kernel is just
> meaningless.  If one still uses the ancient version, [s]he really
> needs to update it.

right, I think we can remove it.. the reason I see is
that we actualy lookup the kernel maps via the map_group
in machine::kmap, which is static.. so always there

if there were no kernel maps events for some reason,
the map group wil be empty and the search will correctly
fail..

I will send it together with some other fixes later this week

thanks,
jirka