linux-kernel - Re: perf confused by modules being loaded in between addresses in /proc/kallsyms

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: <CACVXFVMGTtAPfr3urwLe=UJJKxCaNTLKLOGWc7xu=5vrLU+G3g@mail.gmail.com>
Date:	Thu, 31 Oct 2013 11:22:18 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Michael Hudson-Doyle <michael.hudson@...aro.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Will Deacon <will.deacon@....com>,
	Jean Pihet <jean.pihet@...aro.org>
Subject: Re: perf confused by modules being loaded in between addresses in /proc/kallsyms

Hi Michael,

On Wed, Oct 30, 2013 at 8:53 AM, Michael Hudson-Doyle
<michael.hudson@...aro.org> wrote:
> Hi,
>
> On arm, probably since "ARM: use linker magic for vectors and vector
> stubs" (although I haven't checked this), perf report tends to allocate
> all kernel time to the module loaded at the highest address.
>
> This turns out to be because the "perf_event__synthesize_modules"
> generates a PERF_RECORD_MMAP for the last module thats runs from its
> start to the end of the address space.
>
> This in turn turns out be because the first symbol in /proc/kallsyms is
> now at 0:
>
> # head -n 2 /proc/kallsyms
> 00000000 t __vectors_start

I think it is the root cause, so I posted the below patch to
remove these symbols from /proc/kallsyms days ago:

         http://marc.info/?l=linux-kernel&m=138297540711321&w=2

On ARM, this symbol of zero address is only for generating code, and
won't be run really by CPU, so it shouldn't be in /proc/kallsyms.

> c00081c0 T asm_do_IRQ
>
> /This/ means that the kallsyms entry in machine->kmaps[MAP__FUNCTION] is
> now the first entry rather than the last in the map, so the last module
> is the last in the map and so its "end" stays as ~0ULL.
>
> I'm told that there is no particularly good reason for __vectors_start
> to be in kallsyms at 0, but in any case this seems like a bug in the
> user space tool.  I notice that there is code to split the kallsyms

I am wondering if it is bug in perf utility, since perf may use /proc/kallsyms
to figure out the start address of symbols in kernel address space, but with
the zero address, looks not easy to figure out the real start address of
symbols inside kernel if vmlinux file is missed, then can't parse kernel
IP any more.


Thanks,
-- 
Ming Lei
--
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/