linux-kernel - Re: perf: prctl(PR_TASK_PERF_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: <20120130152935.GA15935@infradead.org>
Date:	Mon, 30 Jan 2012 13:29:35 -0200
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Andrew Steets <asteets@...advisors.com>,
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect

Em Mon, Jan 30, 2012 at 12:01:33PM +0100, Peter Zijlstra escreveu:
> On Mon, 2012-01-30 at 11:11 +0100, Ingo Molnar wrote:
> > So, what workflow are you suggesting to Andrew?
> 
> Librarize perf record, then in your code do something like:
> 
> #include "perf_record.h"
> 
>   handle = perf_record_init(); /* creates perf events and creates
>                                   a record thread that writes samples
>                                   to perf.data, consumes env(PERF_*)
>                                   for configuration, registers with
>                                   at_exit() for cleanup */
>   if (!handle)
>     /* burn */
> 
>   /* do you other code */
> 
>   perf_record_start(handle);
> 
>   /* do the bit you want profiled */
> 
>   perf_record_stop(handle);
> 
> Then build with -lperfrecord or so. Not too hard, right?

This looks like the test__PERF_RECORD function in
tools/perf/builtin-test.c, copying here just the equivalent parts to the
above:

	#include "util/evlist.h"

        struct perf_record_opts opts = {
                .target_pid = -1,
                .target_tid = -1,
                .no_delay   = true,
                .freq       = 10,
                .mmap_pages = 256,
                .sample_id_all_avail = true,
        };

        struct perf_evlist *handle = perf_evlist__new(NULL, NULL);

        /* 
         * We need at least one evsel in the evlist, use the default 
         * one: "cycles". 
         */ 
        err = perf_evlist__add_default(evlist);

	perf_evlist__config_attrs(evlist, &opts);

	err = perf_evlist__open(evlist, opts.group);

        perf_evlist__enable(evlist);

	/* do the bit you want profiled */

        perf_evlist__disable(evlist);


----


perf_evlist__config_attrs will, among other chores, do:

        if (opts->target_pid == -1 && opts->target_tid == -1 &&
            !opts->system_wide) {
                attr->disabled = 1;
                attr->enable_on_exec = 1;
        }

And you can fudge it a bit more to your liking before calling
perf_evlist__open().

	This 'perf test' use case was more for preparing for monitoring
a workload that a program would start, setting up the events, etc,
leaving all disabled and then letting the workload begin which would, by
means of enable_on_exec start the counters/events.

	But I guess you can just setup evlist->workload.pid to getpid()
and use perf_evlist__enable()/ perf_evlist_disable() pairs to your
liking.

	Writing a test case that would do exactly what you want in 'perf
test' would be awesome and would allow us to figure out if the
abstractions in place are enough for your use case. Then we could
librarize just this subset and go from there.

	Take a look as well at test__basic_mmap, it may be useful as
another example of using these evsel/evlist classes.

	What is needed to link you can find in tools/perf/util/setup.py,
remove util/python.c and you should be set.

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