| 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
| ||
|
Message-ID: <Z9BXdbWnX19ua5Mr@x1>
Date: Tue, 11 Mar 2025 12:32:05 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Yicong Yang <yangyicong@...ilicon.com>,
James Clark <james.clark@...aro.org>,
"Dr. David Alan Gilbert" <linux@...blig.org>,
Levi Yun <yeoreum.yun@....com>, Ze Gao <zegao2021@...il.com>,
Weilin Wang <weilin.wang@...el.com>, Xu Yang <xu.yang_2@....com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Howard Chu <howardchu95@...il.com>
Subject: Re: [PATCH v2 11/11] perf python tracepoint: Switch to using
parse_events
On Mon, Mar 10, 2025 at 06:28:01PM -0300, Arnaldo Carvalho de Melo wrote:
> On Mon, Mar 10, 2025 at 02:17:59PM -0700, Ian Rogers wrote:
> > On Mon, Mar 10, 2025 at 2:16 PM Arnaldo Carvalho de Melo
> > <acme@...nel.org> wrote:
> > >
> > > On Mon, Mar 10, 2025 at 06:15:42PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > On Fri, Feb 28, 2025 at 02:23:08PM -0800, Ian Rogers wrote:
> > > > > Rather than manually configuring an evsel, switch to using
> > > > > parse_events for greater commonality with the rest of the perf code.
> > > > >
> > > > > Reviewed-by: Howard Chu <howardchu95@...il.com>
> > > > > Signed-off-by: Ian Rogers <irogers@...gle.com>
> > > >
> > > > Now will all in place I'm trying to test it and I am getting some
> > > > strange results:
> > > >
> > > > root@...ber:/home/acme/git/perf-tools-next# tools/perf/python/tracepoint.py
> > > > <SNIP lots of seemingly ok lines>
> > > > time 78318710956557 prev_comm=sudo prev_pid=3133818 prev_prio=120 prev_state=0x1 ==> next_comm=swapper/14 next_pid=0 next_prio=120
> > > > time 78318720082300 prev_comm=swapper/16 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=kworker/u112:8 next_pid=1752774 next_prio=120
> > > > time 78318706232435 prev_comm=kworker/u112:17 prev_pid=1551246 prev_prio=120 prev_state=0x80 ==> next_comm=swapper/21 next_pid=0 next_prio=120
> > > > time 78318708202121 prev_comm=sudo prev_pid=3133818 prev_prio=120 prev_state=0x2 ==> next_comm=swapper/25 next_pid=0 next_prio=120
> > > > time 78318748346989 prev_comm=swapper/26 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=gnome-terminal- next_pid=3551 next_prio=120
> > > > Traceback (most recent call last):
> > > > File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 47, in <module>
> > > > main()
> > > > File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 42, in main
> > > > event.next_comm,
> > > > ^^^^^^^^^^^^^^^
> > > > AttributeError: 'perf.sample_event' object has no attribute 'next_comm'
> > > > root@...ber:/home/acme/git/perf-tools-next#
> > > >
> > > > But it shouldn't get there as there is this check:
> > > >
> > > > if not isinstance(event, perf.sample_event):
> > > > continue
> > > >
> > > >
> > > > :-\
> > > >
> > > > Trying to debug that...
> > >
> > > And it doesn't seem related to your series, I checked and v6.13 has the
> > > same problem, I nuked the build dir, etc.
> >
> > Right. I'd seen the same issue.
>
> time 79411977132102 prev_comm=sudo prev_pid=3133818 prev_prio=120 prev_state=0x2 ==> next_comm=swapper/12 next_pid=0 next_prio=120
> { type: sample }
> time 79411977200343 prev_comm=kworker/u112:17 prev_pid=1551246 prev_prio=120 prev_state=0x80 ==> next_comm=swapper/16 next_pid=0 next_prio=120
> { type: sample }
> time 79411964535268 prev_comm=kworker/u112:14 prev_pid=810939 prev_prio=120 prev_state=0x80 ==> next_comm=swapper/17 next_pid=0 next_prio=120
> { type: sample }
> time 79411964746511 prev_comm=swapper/18 prev_pid=0 prev_prio=120 prev_state=0x0 ==> next_comm=kworker/u112:12 next_pid=2109251 next_prio=120
> { type: sample }
> Traceback (most recent call last):
> File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 48, in <module>
> main()
> File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 43, in main
> event.next_comm,
> ^^^^^^^^^^^^^^^
> AttributeError: 'perf.sample_event' object has no attribute 'next_comm'
> root@...ber:/home/acme/git/perf-tools-next#
>
> And it says it is a sample...
>
> Well, ran out of time, will try later or early tomorrow, will also try
> to review the syscalltbl series and Howard's off cpu profiling.
Its some sort of corruption, I added printing the sample_* fields and
then up to the field before next_comm:
time 2462907120158 prev_comm=swapper/8 prev_pid=0 prev_prio=120 prev_state=0x0 ==>
next_comm=gnome-terminal- next_pid=3646 next_prio=120
ip 0 pid=0 tid=0 cpu=12
time 2462916970223 prev_comm=swapper/12 prev_pid=0 prev_prio=120 prev_state=0x0 ==>
next_comm=gnome-terminal- next_pid=3646 next_prio=120
ip 0 pid=0 tid=0 cpu=14
time 2462902120635 prev_comm= prev_pid=1919907691 prev_prio=796026219 prev_state=0x323a32313175 ==>
Traceback (most recent call last):
File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 51, in <module>
main()
File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 46, in main
event.next_comm,
^^^^^^^^^^^^^^^
AttributeError: 'perf.sample_event' object has no attribute 'next_comm'
root@...ber:/home/acme/git/perf-tools-next#
See the empty prev_comm, bogus pref_pid, ditto for prev_state and
pref_prio and then it simple doesn't have that next_comm...
Also I noticed that in tracepoint_field() (tools/perf/util/python.c) we
can get the string tracepoint fields as a bytearray or as a string,
ahere:
if (field->flags & TEP_FIELD_IS_STRING &&
is_printable_array(data + offset, len)) {
ret = PyUnicode_FromString((char *)data + offset);
} else {
ret = PyByteArray_FromStringAndSize((const char *) data + offset, len);
field->flags &= ~TEP_FIELD_IS_STRING;
}
For some reason in sessions where bytearrays are returned, and all comes
as bytearrays, the problem is not noticed.
But when it comes as a string it breaks after a short time, /me
scratches head...
- Arnaldo
Powered by blists - more mailing lists