linux-kernel - Re: [PATCH 02/16] perf: Add ability to attach registers dump to sample

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: <20120524115206.GB1775@m.brq.redhat.com>
Date:	Thu, 24 May 2012 13:52:06 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Stephane Eranian <eranian@...gle.com>, acme@...hat.com,
	mingo@...e.hu, paulus@...ba.org, cjashfor@...ux.vnet.ibm.com,
	fweisbec@...il.com, gorcunov@...nvz.org, tzanussi@...il.com,
	mhiramat@...hat.com, robert.richter@....com, fche@...hat.com,
	linux-kernel@...r.kernel.org, masami.hiramatsu.pt@...achi.com,
	drepper@...il.com, asharma@...com, benjamin.redelings@...cent.org
Subject: Re: [PATCH 02/16] perf: Add ability to attach registers dump to
 sample

On Thu, May 24, 2012 at 12:42:22PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-05-24 at 12:06 +0200, Stephane Eranian wrote:
> 
> > > What are we doing here and why?
> > >
> > I think this is related to a discusion we had earlier about which
> > machine state you want
> > to sample.
> > 
> > There are 3 possible machine states:
> >   1- user level (even when sample is in kernel AND assuming you did
> > not hit a kernel only thread)
> >   2- interrupted state (@ PMU interrupt)
> >   3- precise state (state captured by PEBS on Intel, for instance)
> > 
> > Jiri is only interested in 1/. I am interested in the other two as well.
> > 
> > Question: is there a situation where we could need more than one machine
> > state per sample?
> 
> Well, IIRC you always wanted both 2 and 3 at the same time to compute
> skid, thus:
> 
> > If not, then a single bitmask is enough.
> 
> Indeed, so then we get to multiple bitmasks and unless you want to be
> restricted to the same bitmap for all these types this setup won't
> actually work.

My intention was to make this general. I could just add
bitmask for each type (user regs mask for now) but I wanted
to be consistent with other SAMPLE_* stuff..

So current patch adds PERF_SAMPLE_REGS sample_type bit.
Once it is set, the 'sample_regs' value is checked for what
type of registers you want for sample.

Each type then has separate bitmask in case you want different
registers for each type. Allowing whatever combination of regs dump
being added to the sample, since it seems there's no firm
decision on what combination might be needed.

Sure we can make the same with bitmasks for each regs type,
and check the presence in sample by bitmask being not empty.
--
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/