linux-kernel - Re: [BUG] perf report: ordered events and flushing bug

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:	Thu, 12 Mar 2015 16:06:46 -0400
From:	Stephane Eranian <eranian@...gle.com>
To:	David Ahern <dsahern@...il.com>
Cc:	Adrian Hunter <adrian.hunter@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [BUG] perf report: ordered events and flushing bug

On Thu, Mar 12, 2015 at 3:53 PM, David Ahern <dsahern@...il.com> wrote:
> On 3/12/15 1:39 PM, Stephane Eranian wrote:
>>
>> What the point of having all the ordered event logic if you are saying
>> events
>> must be saved in order. I don't think there is a way to make that
>> guarantee
>> when monitoring multiple CPUs at the same time.
>
>
> The record command does not analyze the events, it just copies from mmap to
> file in lumps per mmap. e.g., on a given round the perf data file has events
> like this:
>
>    111112223344444444555566666F111111111
>    |<------- round --------->|^
>                               |
>         finished round event -|
>
> where 11111 are events read from mmap1, 2222 are events from mmap2, etc. F
> is the finished round event which a pass over all mmaps has been done.
>
> So for mmap1 all of the 11111 events are in time order, then jumping to
> mmap2 events the 2222 times are time sorted relative to mmap2 but not
> relative to mmap1 events.
>
> The ordered events code sorts the clumps into a time based stream:
>     123141641445124564234645656...
>
In my case I care about time ordering the mmap records between themselves
because they overlap on the address range.

t0: 0x100000-0x200000 //anon

t10: sample @ 0x100600
t20: sample @ 0x100250

t1: 0x100600-0x100700 jit2
t2: 0x100200-0x100300 jit3

with t1 < t2 < t2 < t10

I inject t1, t2 mmaps at the end of the perf.data file.

The full ordering should yield:

t0: 0x100000-0x200000 //anon
t1: 0x100600-0x100700 jit2
t2: 0x100200-0x100300 jit3
t10: sample @ 0x100600 -> jit2
t20: sample @ 0x100250 -> jit3

Partial ordering would likely yield both samples pointing to //anon.
--
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/