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:03:50 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	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 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.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ