linux-kernel - Re: [PATCH v8 02/14] perf: Add AUX area to ring buffer for raw data streams

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: <87d26knnvp.fsf@ashishki-desk.ger.corp.intel.com>
Date:	Mon, 12 Jan 2015 15:12:58 +0200
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	"Metzger\, Markus T" <markus.t.metzger@...el.com>
Cc:	Ingo Molnar <mingo@...hat.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	Robert Richter <rric@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>,
	"Liang\, Kan" <kan.liang@...el.com>,
	"Hunter\, Adrian" <adrian.hunter@...el.com>,
	"mathieu.poirier\@linaro.org" <mathieu.poirier@...aro.org>,
	"acme\@infradead.org" <acme@...radead.org>
Subject: Re: [PATCH v8 02/14] perf: Add AUX area to ring buffer for raw data streams

Peter Zijlstra <peterz@...radead.org> writes:

> On Mon, Nov 17, 2014 at 09:33:00AM +0000, Metzger, Markus T wrote:
>> > From: Peter Zijlstra <peterz@...radead.org>
>> > 
>> > This patch introduces "AUX space" in the perf mmap buffer, intended for
>> > exporting high bandwidth data streams to userspace, such as instruction
>> > flow traces.
>> > 
>> > AUX space is a ring buffer, defined by aux_{offset,size} fields in the
>> > user_page structure, and read/write pointers aux_{head,tail}, which abide
>> > by the same rules as data_* counterparts of the main perf buffer.
>> > 
>> > In order to allocate/mmap AUX, userspace needs to set up aux_offset to
>> > such an offset that will be greater than data_offset+data_size and
>> > aux_size to be the desired buffer size. Both need to be page aligned.
>> > Then, same aux_offset and aux_size should be passed to mmap() call and
>> > if everything adds up, you should have an AUX buffer as a result.
>> 
>> Why would userspace need to fill in aux_offset and aux_size?  Can't the kernel
>> do this when userspace mmaps the aux buffer like it does for the respective
>> data_* fields?
>
> I suppose we could; I'm trying to remember why I did it like this, I'm
> failing to remember much past yesterday atm :/ 

Well, right now we can only map things in one order: user page + perf
buffer, then aux buffer. Ideally, we can reduce it to mapping the user
page first (always R/W), setting up the desired offsets for data and aux
buffers and then mapping those in whatever order. And we can also have
holes between them if we want (not sure if that's useful, though).

If we want to stick to the current scheme of things where user page is
mapped together with data, we should set up aux_{offset,size} in
kernel's perf_mmap() path, similarly to data_{offset,size}.

There is another problem with it, though: it makes it impossible to run
the aux buffer in "full trace mode" (where we move the tail as we read
the data out), while running the data buffer in overwrite mode, because
the latter requires the user_page to be mapped RO => no way to update
aux_tail for the user.

>> How would userspace fill in those fields if it mapped the data buffer read-only?
>
> Good point, its not used much atm. But yes. That also reminds me; we
> should probably finish this:
>
>   https://lkml.org/lkml/2013/7/8/154

Indeed, it's been on my todo list for some time.

Regards,
--
Alex
--
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/