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]

Message-ID: <55015634.6080101@intel.com>
Date:	Thu, 12 Mar 2015 11:02:44 +0200
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Stephane Eranian <eranian@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>
CC:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>, David Ahern <dsahern@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [BUG] perf report: ordered events and flushing bug

On 12/03/15 05:32, Stephane Eranian wrote:
> Hi,
> 
> I am working on the JIT support to improve the flow and have
> perf record inject the MMAPs at the end of the collection. For
> that I piggyback on the buildid pass. To avoid rewriting the entire perf.data
> file, I simply append the the MMAP records at the end of the file. And that
> puts them out-of-order in time systematically. But I thought it would be okay
> because perf report would sort them by timestamps again.
> 
> Well, it does not in all cases! Why?
> 
> Because of the round flushing. Based on how far out-of-order an event is,
> it may not be processed correctly because of round flushing. I believe this
> may only impact MMAP records.  This is a serious issue because
> mmaps drive symbolization of samples. If samples are processed without the
> proper dso mapping, then samples may not be symbolized or may be wrongly
> symbolized.
> 
> So far, the workaround I found was to set the oe->next_flush = 0 for
> the ROUND mode.
> In other words, do not flush anything until FINAL. To me, this is the
> only sensible
> way of avoiding this kind of problems. I am not sure I understand the
> point of flushing
> anyway, except to minimize memory footprint, maybe. But it does not
> work with vastly
> out-of-order mmaps.
> 
> Do you have a better solution?

You could hook the ordered event delivery (see Arnaldo's perf/core branch):

if (tool->ordered_events) {
	inject->deliver = session->ordered_events.deliver;
	session->ordered_events.deliver = jit_mmap_deliver;
}

int jit_mmap_deliver(struct ordered_events *oe, struct ordered_event *event, struct perf_sample *sample)
{
	struct perf_inject *inject = container_of(oe->tool, struct perf_inject, tool);

	if (next_jit_mmap_time < sample->time) {
		<synth mmap event>
		perf_session__deliver_synth_event(...);
	}	
	return inject->deliver(oe, event, sample);
}

Need to get Arnaldo's comment on this approach first though.

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