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: <20150112133841.GB25256@twins.programming.kicks-ass.net>
Date:	Mon, 12 Jan 2015 14:38:41 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	"Metzger, Markus T" <markus.t.metzger@...el.com>,
	Ingo Molnar <mingo@...hat.com>,
	"linux-kernel@...r.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@...aro.org" <mathieu.poirier@...aro.org>,
	"acme@...radead.org" <acme@...radead.org>
Subject: Re: [PATCH v8 02/14] perf: Add AUX area to ring buffer for raw data
 streams

On Mon, Jan 12, 2015 at 03:12:58PM +0200, Alexander Shishkin wrote:
> > 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).

Indeed, over the weekend I came up a similar argument. Suppose we want
to extend the thing with yet another area, at that point we simply do
not know which segment is meant to be mapp()ed.

Breaking up the control page from the data buffer is indeed a sane
proposal.

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

ISTR aux bits relying on their own mmap(PROT_WRITE) bit, but yes-ish.
--
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/