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

Message-ID: <87ob67y3xo.fsf@canonical.com>
Date:	Tue, 29 Oct 2013 17:53:39 -0700
From:	Michael Hudson-Doyle <michael.hudson@...aro.org>
To:	linux-kernel@...r.kernel.org
Cc:	Jiri Olsa <jolsa@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Will Deacon <will.deacon@....com>,
	Jean Pihet <jean.pihet@...aro.org>
Subject: perf confused by modules being loaded in between addresses in /proc/kallsyms

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
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
symbols around symbols from modules (dso__split_kallsyms) but this
doesn't seem to be called for record, only report.  Is the fix as simple
as making sure this happens for record as well?  I don't feel qualified
to answer that.

Cheers,
mwh
--
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/