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

Powered by blists - more mailing lists