linux-kernel - Re: PERF_EVENT_IOC_SET

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:	Wed, 2 Oct 2013 12:29:56 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Adrian Hunter <adrian.hunter@...el.com>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	"Kleen, Andi" <andi.kleen@...el.com>,
	"Shishkin, Alexander" <alexander.shishkin@...el.com>
Subject: Re: PERF_EVENT_IOC_SET_OUTPUT

On Wed, Oct 02, 2013 at 12:03:50PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 01, 2013 at 10:11:56PM +0300, Adrian Hunter wrote:
> > Hi
> > 
> > It does not seem possible to use set-output between
> > task contexts of different types (e.g. a software event
> > to a hardware event)
> > 
> > If you look at perf_event_set_output():
> > 
> >           /*
> >            * If its not a per-cpu rb, it must be the same task.
> >            */
> >           if (output_event->cpu == -1 && output_event->ctx != event->ctx)
> >                   goto out;
> > 
> > ctx (perf_event_context) won't be the same for events
> > of different types.  Is this restriction necessary?
> 
> Hmm.. so last night I wrote me a big reply saying we couldn't do it;
> then this morning I reconsidered and thing that something like:
> 
>   output_event->ctx->task != event->ctx->task
> 
> should actually work.
> 
> The reason it should be OK I think is because perf_mmap() will refuse to
> create a buffer for inherited events that have ->cpu == -1.
> 
> My initial response was going to say that it wouldn't be possible
> because __perf_event_task_sched_out() could 'break' one ctx while still
> swapping the other, at which point the buffer would have to service two
> different tasks, potentially from different CPUs and with the buffers
> not actually being SMP safe that's a problem.

I don't get what you mean with breaking or swapping a ctx.
But I can confirm that perf_mmap() won't allow a buffer to be remotely
accessed from another CPU. Now there may be other issues than locality which
I'm missing :)

> 
> But like stated, perf_mmap() seems to avoid that issue entirely by not
> allowing inherited events that aren't cpu bound.
> 
> Someone please double check this..  :-)
--
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/