[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251126102401.37af98bb@gandalf.local.home>
Date: Wed, 26 Nov 2025 10:24:01 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Thomas Richter <tmricht@...ux.ibm.com>
Cc: Namhyung Kim <namhyung@...nel.org>, linux-kernel@...r.kernel.org,
linux-s390@...r.kernel.org, linux-perf-users@...r.kernel.org,
acme@...nel.org, agordeev@...ux.ibm.com, gor@...ux.ibm.com,
sumanthk@...ux.ibm.com, hca@...ux.ibm.com, japo@...ux.ibm.com
Subject: Re: [PATCH Linux-next] perf test: Fix test case perf trace BTF
general tests
On Wed, 26 Nov 2025 08:13:00 +0100
Thomas Richter <tmricht@...ux.ibm.com> wrote:
> >> I haven't tried it without the patches. Does it usually show what "buf" is?
> >> Now with the reading of user space, it can show the content too!
> >
> > Yep, it reads the content using BPF. This is on my 6.16 kernel.
> >
> > $ sudo perf trace -e write -- /bin/echo hello
> > hello
> > 0.000 ( 0.014 ms): echo/61922 write(fd: 1, buf: hello\10, count: 6) = 6
> >
> > Thanks,
> > Namhyung
> >
> >
>
> Hello Namhyung, Steven,
>
> friendly ping... any progress here?
>
I honestly have no clue how to fix this, as I don't even know where to
look. Is it BPF that is messing up? If so, where's the BPF program that is
doing this.
I thought BPF is supposed to handle updates and should never cause API
breakage?
I'll continue to look at the builtin-trace.c, but it seems that the BPF
program it's attached to is handing it garbage with:
perf trace -e syscalls:sys_enter_write
The new fields are at the end. The BPF program should simply ignore those
values. But again, I don't know where this BPF program lives.
-- Steve
Powered by blists - more mailing lists