linux-kernel - Re: perf: problem of 32bit mmap call graph recording

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]

Date:	Wed, 17 Aug 2011 15:19:04 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Lin Ming <ming.m.lin@...el.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Huang, Ying" <ying.huang@...el.com>,
	"He, Fan F" <fan.f.he@...el.com>
Subject: Re: perf: problem of 32bit mmap call graph recording

On Wed, Aug 17, 2011 at 04:20:03PM +0800, Lin Ming wrote:
> Hi all, 
> 
> On 32 bit machine, we have problem to get the usersapce call graph of
> mmap syscall.
> 
> You can reproduce it with below command on 32bit machine.
> 
> sudo perf record -f -g -e raw_syscalls:sys_enter --filter "id==192" ls
> 
> sudo perf report |less
> 
> # Events: 26 
> #
> # Overhead  Command      Shared Object  Symbol
> # ........  .......  .................  ......
> #
>    100.00%       ls  [kernel.kallsyms]  [k] syscall_trace_enter
>                  |
>                  --- syscall_trace_enter
>                      syscall_trace_entry
>                     |          
>                     |--88.46%-- __mmap  <--- only __mmap, no more userspace call stacks
>                     |          
>                      --11.54%-- 0xffffe424
> 
> 
> Kernel relies on userspace bp register to get call graph information.
> But for mmap syscall, the bp register is used to pass in the sixth
> parameter(offset).
> 
> void *mmap(void *addr, size_t length, int prot, int flags,
>                   int fd, off_t offset);
> 
> Anyway to fix this issue on 32bit machine?

Ah... Well we can't do much about that I fear :)
The only way would be to rely on dwarf informations to do the
unwind. The upside is that it would work about everywhere
even on places that don't have frame pointers, the downside
is some overhead on sample records (dump a bunch of stack every
sample) and a lot of work :)
--
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/