linux-kernel - Re: [RFC 2/2] 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: <20140515180218.GA32115@rric.localhost>
Date:	Thu, 15 May 2014 20:02:18 +0200
From:	Robert Richter <rric@...nel.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.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>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC 2/2] perf: add AUX area to ring buffer for raw data streams

On 15.05.14 18:08:30, Alexander Shishkin 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.
> The latter is not forced to be a power of 2 number of pages, so that PMU
> drivers have to take care of this if necessary in their implementations
> of ->alloc_aux(). 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.

Raw data sample (PERF_SAMPLE_RAW) already allow to pass data to
userspace. What is the reason for a separate buffer? I see the
following:

 * the buffer accessed from userspace should have a customized format
   unrelated to perf,

 * zero copying (not sure if this is really possible),

 * data size and alignment requirements that can not be handled by raw
   data samples.

If possible, raw data samples should be a first option.

On the other side there might the need of an aux buffer (I would
better call it raw buffer analog to raw data). So here some comments
on the implementation and the user i/f.

Instead of extending the current ringbuffer I would better add a 2nd
ring buffer. The mmap and ringbuffer handling and esp. the access from
userspace looks much more complex now and it was already complex
before. So with a 2nd buffer there would be less changes in the
implementation and handling. Access from userland would remain as it
currently is, there is no need to modify the header page layout. To
setup a 2nd buffer, you just need to modify the mmap call in a way
(maybe by prot, flags or offset argument) to let the kernel know an
aux buffer should be attached to the event.

Then, instead of introducing a new PERF_RECORD_AUX, just reuse
PERF_RECORD_SAMPLE. If an aux/raw buffer is connected to the event,
then the data is not part of the sample but passed to the raw buffer.

Tools, interfaces and helper functions would work already with such
raw samples, just the raw buffer handling need to be added.

How about this?

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