linux-kernel - Re: perf script: Question: Python trace processing script contains the tid of the process in the common

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170705192545.GI27350@kernel.org>
Date:   Wed, 5 Jul 2017 16:25:45 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Arun Kalyanasundaram <arunkaly@...gle.com>
Cc:     Arnaldo Carvalho de Melo <acme@...hat.com>,
        Tom Zanussi <tzanussi@...il.com>, linux-kernel@...r.kernel.org,
        David Carrillo-Cisneros <davidcc@...gle.com>
Subject: Re: perf script: Question: Python trace processing script contains
 the tid of the process in the common_pid attribute

Em Wed, Jul 05, 2017 at 09:22:07AM -0700, Arun Kalyanasundaram escreveu:
> Hi Arnaldo,
> 
> Thank you for your reply.
> I actually meant tracepoint event handlers: def
> trace_unhandled(event_name, context, event_fields_dict)
> The dict parameter contains an attribute "common_pid" which is
> actually the "tid" of the thread. There are no other attributes that
> contain the actual pid of the process. So, I was wondering if this is
> something intentional? If not I can share a patch to fix this.

Yeah there is a problem in:

tools/perf/util/scripting-engines/trace-event-python.c

static void python_process_event(union perf_event *event,
                                 struct perf_sample *sample,
                                 struct perf_evsel *evsel,
                                 struct addr_location *al)
{
        struct tables *tables = &tables_global;

        switch (evsel->attr.type) {
        case PERF_TYPE_TRACEPOINT:
                python_process_tracepoint(sample, evsel, al);
                break;
        /* Reserve for future process_hw/sw/raw APIs */
        default:
                if (tables->db_export_mode)
                        db_export__sample(&tables->dbe, event, sample, evsel, al);
                else
                        python_process_general_event(sample, evsel, al);
        }
}

The python_process_tracepoint() thing predates
python_process_general_event(), and doesn't adds the dict with all the
perf_sample entries that python_process_general_event() passes to the
python method :-\

Both the per-tracepoint python hooks _and_ trace_unhandled() should get
that dict, is that what your patch does?

- Arnaldo
 
> Best,
> - Arun
> 
> 
> On Sat, Jul 1, 2017 at 7:47 AM, Arnaldo Carvalho de Melo
> <acme@...hat.com> wrote:
> > Em Fri, Jun 30, 2017 at 03:40:57PM -0700, Arun Kalyanasundaram escreveu:
> >> The handlers in the python script generated from "perf script" have an
> >> attribute: common_pid. This attribute contains the tid of the process
> >> instead of its pid. I would like to know if this is the expected behavior.
> >> There are no other attributes in the Python handler that provide the pid
> >> and knowing the process id is useful to be able to group all samples that
> >> belong to the same process that generated different threads.
> >
> > Humm, you have:
> >
> > def process_event(param_dict):
> >         event_attr = param_dict["attr"]
> >         sample     = param_dict["sample"]
> >         raw_buf    = param_dict["raw_buf"]
> >         comm       = param_dict["comm"]
> >         name       = param_dict["ev_name"]
> >
> > And then, on sample you have (from a recent python script for processing
> > Intel PT samples):
> >
> > def print_common_start(comm, sample, name):
> >        ts = sample["time"]
> >        cpu = sample["cpu"]
> >        pid = sample["pid"]
> >        tid = sample["tid"]
> >        print "%16s %5u/%-5u [%03u] %9u.%09u %7s:" % (comm, pid, tid, cpu, ts / 1000000000, ts %1000000000, name),
> >
> > - Arnaldo