linux-kernel - Re: [PATCH -tip v3 0/6] perf: Introduce branch sub commands

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: <20110401125129.GA2335@nowhere>
Date:	Fri, 1 Apr 2011 14:51:39 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Akihiro Nagai <akihiro.nagai.hw@...achi.com>
Cc:	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	2nddept-manager@....hitachi.co.jp, David Ahern <daahern@...co.com>
Subject: Re: [PATCH -tip v3 0/6] perf: Introduce branch sub commands

On Fri, Apr 01, 2011 at 07:57:05PM +0900, Akihiro Nagai wrote:
> (2011/03/30 23:46), Frederic Weisbecker wrote:
> <snip>
> >>'perf branch trace' can parse and analyze recorded BTS log and print various
> >>information of execution path. This command can show address, pid, command name,
> >>function+offset, file path of elf.
> >>You can choose the printed information with option.
> >>
> >>Example: 'perf branch trace'
> >>function+offset
> >>irq_return+0x0  =>  _start+0x0
> >>irq_return+0x0  =>  _start+0x0
> >>_start+0x3      =>  _dl_start+0x0
> >>irq_return+0x0  =>  _dl_start+0x0
> >>irq_return+0x0  =>  _dl_start+0x26
> >>irq_return+0x0  =>  _dl_start+0x2d
> >
> >These results are a bit surprising. May be we can
> >jump once from irq_return to _start, in the first schedule()
> >of a new task perhaps, but thereafter I would expect
> >further jumps not to happen from irq_return, but rather
> >from _start. When we have x as a destination in line n, then
> >I would expect to have x as a source in n + 1.
> Agree with the opinion "irq_start" surprising users.
> However, I think it is not a better solution that uses a
> previous destination as a next source.
> Because, users want to know what happen in userspace and,
> do not want to know interrupts from kernel.
> 
> I think the better solution is to implement the filter that
> eliminate the record including kernel functions from output.

Yep.

> For example, leading example will be filtered like this.
> 
> _start+0x3      =>  _dl_start+0x0
> 
> In the future, I think the solution is available that using BTS records
> with trace event like irq:irq_handler_entry to analyze interrupt.
> However, to do it, we need to fix perf.

Right.
 
> >
> >Also we are supposed to only trace BTS in userspace, but
> >perhaps, if we are interrupted, after the execution of the iret instruction,
> >BTS considers the following jump "iret ->  interrupted inst" as a branch
> >in userspace. After all it makes sense, it is a jump in userspace.
> >
> >So BTS, because of the way it defines a jump inside userspace,
> >traces irq returns but not irq entries, that would explain the trace
> >you gave as an example.
> >
> >I suspect we want to filter irq returns. ie: if the source comes
> >from the kernel, then filter it by default. And then we can later
> >think about an option to enable interrupt return tracing if
> >people want them.
> Agree.
> I will implement the option that enable/disable the filter.

Cool, thanks!
--
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/