linux-kernel - RE: [PATCH V5 14/16] perf, x86: enable LBR callstack when recording callchain

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: <37D7C6CF3E00A74B8858931C1DB2F077016111A4@SHSMSX103.ccr.corp.intel.com>
Date:	Tue, 7 Oct 2014 16:04:11 +0000
From:	"Liang, Kan" <kan.liang@...el.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	"eranian@...gle.com" <eranian@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"paulus@...ba.org" <paulus@...ba.org>,
	"acme@...nel.org" <acme@...nel.org>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	"Yan, Zheng" <zheng.z.yan@...el.com>
Subject: RE: [PATCH V5 14/16] perf, x86: enable LBR callstack when recording
 callchain



> 
> On Tue, Oct 07, 2014 at 03:00:43AM +0000, Liang, Kan wrote:
> >
> >
> > >
> > > On Wed, Sep 10, 2014 at 10:09:11AM -0400, kan.liang@...el.com wrote:
> > > > From: Kan Liang <kan.liang@...el.com>
> > > >
> > > > If a task specific event wants user space callchain but does not
> > > > want branch stack sampling, enable the LBR call stack facility implicitly.
> > > > The LBR call stack facility can help perf to get user space
> > > > callchain in case of there is no frame pointer.
> > > >
> > > > Note: this feature only affects how to get user callchain. The
> > > > kernel callchain is always got by frame pointers.
> > >
> > > Yeah, don't like this either. Suppose you have sane userspace (with
> > > framepointers enabled) then you're now loosing the better option.
> >
> > FP is the first option. This patch tries to enable LBR call stack facility implicitly.
> > Only when FP disabled or failed, we try to use LBR call stack.
> > Please refer to the previous patch https://lkml.org/lkml/2014/9/10/376
> 
> Still makes for an entirely unpredictable situation. That way you never quite
> know where your data came from.

But the problem is that we don't know if FP works in advance. We can only
check during runtime. So we have to keep the LBR running.
The process is  fixed. The FP will be checked first.
Only FP failed, LBR data is used. 
If the user want to know where the data come from, we may implement
a flag for user perf tool. 

Kan
--
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/