linux-kernel - Re: [PATCH V5 4/6] perf, x86: handle multiple records in PEBS buffer

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]

Date:	Mon, 30 Mar 2015 22:07:10 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Liang, Kan" <kan.liang@...el.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"acme@...radead.org" <acme@...radead.org>,
	"eranian@...gle.com" <eranian@...gle.com>
Subject: Re: [PATCH V5 4/6] perf, x86: handle multiple records in PEBS buffer

On Mon, Mar 30, 2015 at 05:43:45PM +0000, Liang, Kan wrote:
> As my understanding, Peter means the multiple PEBS bits could be set
> when sampling only one single event.  
> 
> Peter, could you please clarify?

So the chain of events of a PEBS counter is as follows:

 A) the CTRn value reaches 0:
    - the corresponding bit in GLOBAL_STATUS gets set
    - we start arming the hardware assist

<unspecified amount of time later --
	this could cover multiple events of interest>

 B) the hardware assist is armed, any next event will trigger it

 C) a matching event happens:
    - the hardware assist triggers and generates a PEBS record
      this includes a copy of GLOBAL_STATUS at this moment
    - if we auto-reload we (re)set CTRn
    - we clear the relevant bit in GLOBAL_STATUS

CASE 1:

Now if we have a chain of events like:

 A0, B0, A1, C0

The event generated for counter0 will include a status with counter1
set, even though its not at all related to the record. A similar thing
can happen with a !PEBS event if it just happens to overflow at the
right moment.

CASE 2:

If otoh we modify things like:

 A0, B0, A1, B1, C01

Where C01 is an event that triggers both hardware assists (the
instruction matches both criteria), we will generate but a single
record, but again with both counters listed in the status field.

This time the record pertains to both.

Note that these two cases are different but undistinguishable with the
data as generated -- although one can try and infer given future events.
The first case must continue to generate an event for counter1
(hopefully with counter0 clear, otherwise continue with the induction
until you get a record with but one set).

Also note that its not entirely clear in case two if the event needs to
be the very same or just 'close', this is not (well) specified, but
conceptually the case presented is the easier.
--
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/