linux-kernel - Re: [PATCH Linux-next] perf test: Fix test case perf trace BTF general tests

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: <20251126121229.0638407b@gandalf.local.home>
Date: Wed, 26 Nov 2025 12:12:29 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: acme@...nel.org
Cc: Thomas Richter <tmricht@...ux.ibm.com>, Namhyung Kim
 <namhyung@...nel.org>, linux-kernel@...r.kernel.org,
 linux-s390@...r.kernel.org, linux-perf-users@...r.kernel.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


Arnaldo,

How can I make perf trace not confused by the extra fields in the system
call trace events?

Ftrace can now show the contents of the system call user space buffers, but
it appears that this breaks perf!!!

system: syscalls
name: sys_enter_write
ID: 791
format:
	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
	field:int common_pid;	offset:4;	size:4;	signed:1;

	field:int __syscall_nr;	offset:8;	size:4;	signed:1;
	field:unsigned int fd;	offset:16;	size:8;	signed:0;
	field:const char * buf;	offset:24;	size:8;	signed:0;
	field:size_t count;	offset:32;	size:8;	signed:0;
	field:__data_loc char[] __buf_val;	offset:40;	size:4;	signed:0;

That new __buf_val appears to confuse perf, but I'm having a hell of a time
trying to figure out where it reads it!

-- Steve


On Wed, 26 Nov 2025 10:24:01 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> 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