linux-kernel - Re: [RFC PATCH 0/3] Perf persistent events

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: <20130329142504.GA5374@nazgul.tnic>
Date:	Fri, 29 Mar 2013 15:25:04 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Robert Richter <rric@...nel.org>
Cc:	Ingo Molnar <mingo@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Borislav Petkov <bp@...e.de>
Subject: Re: [RFC PATCH 0/3] Perf persistent events

On Thu, Mar 28, 2013 at 04:52:29PM +0100, Robert Richter wrote:
> An option would be to attach the persistent events to a hosting pmu
> (e.g. 'ras' in this case) and provide the events via sysfs as already
> done by other pmus:
> 
>  /sys/bus/event_source/devices/ras/events/
>  /sys/bus/event_source/devices/ras/events/mce_record
>  ...
> 
> perf tools work then out-the-box with -e ras/mce_record/.
> 
> The event is selected by the 'ras' pmu and then routed to the original
> pmu that might be e.g. 'tracepoint'. So we attach each persistent
> event to a 'virtual' pmu which does the grouping in the perf sysfs and
> the forwarding to its actual pmu.

As I told you already in IRC, persistent events should be completely
generic and not only related to ras. IOW, *all* possible events we have
now should be also be able to be created as persistent. What I mean is:

perf -e kvm:kvm_page_fault:P ... <target_task>

should mean that I want to collect *all* kvm page faulting events during
the system's lifetime not only during target_task executes.

And the "P" I've chosen arbitrary to mean persistent.

Which raises a couple more questions like what would happen with those
events once the perf tool call above exits. Obviously, the event should
stay enabled. Also, a subsequent call of this would mean "do not open
another persistent event of this type but give the persistent file
descriptor instead" and so on and so on.

Now, this probably can be solved with a virtual 'persistent' pmu which
'hosts' all persistent events. The question is, do we want to do it this
way?

What do the others think?

P.S. Btw, some of the concerns you've raised in your other mail have
been already addressed here:

git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git persistent5

and I'll look at the remaining ones when I get back.

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