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] [day] [month] [year] [list]
Message-ID: <aRwVifZ_-7puFUVC@google.com>
Date: Mon, 17 Nov 2025 22:43:21 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Thomas Richter <tmricht@...ux.ibm.com>,
	Steven Rostedt <rostedt@...dmis.org>
Cc: 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 Tue, Nov 18, 2025 at 07:15:45AM +0100, Thomas Richter wrote:
> On 11/18/25 02:58, Namhyung Kim wrote:
> > Hello,
> > 
> > On Mon, Nov 17, 2025 at 01:43:59PM +0100, Thomas Richter wrote:
> >> The following test case fails on linux-next repo:
> >>
> >>  ❯ uname -a
> >>  Linux s83lp47.lnxne.boe 6.18.0-20251116.rc5.git0.0f2995693867.63.\
> >>       fc42.s390x+next #1 SMP Sun Nov 16 20:05:28 CET 2025 s390x GNU/Linux
> >>
> >>  # perf test -Fv 109
> >>  --- start ---
> >>  Checking if vmlinux BTF exists
> >>  Testing perf trace's string augmentation
> >>  Testing perf trace's buffer augmentation
> >>  Buffer augmentation test failed, output:
> >>  buffer content
> >>  echo/23281 write(1, buffer conten, 15, "") = 15
> >>  ---- end ----
> >>  109: perf trace BTF general tests            : FAILED!
> >>  #
> >>
> >> The root case is a changed output format on linux-next.
> >> There is an addional "" string as forth parameter in the write()
> >> line. Here is the detailed output on linux-repo.
> >> Please note that this depends on the kernel and not on the perf tool.
> > 
> > Thanks for the report.  Do you know what the 4th arg is?  It'd be nice
> > if you can dump the contents of the event format which is
> > /sys/kernel/tracing/events/syscalls/sys_enter_write/format.
> > 
> > Thanks,
> > Namhyung
> > 
> 
> Here is the output from my x86 virtual machine with linux-next 20251114 tag.

Thanks for sharing this!

> 
> bash-5.3# uname -a
> Linux f43 6.18.0-rc5-next-20251114tmr-n #1 SMP PREEMPT_DYNAMIC Mon Nov 17 11:24:02 CET 2025 x86_64 GNU/Linux
> bash-5.3# cat /sys/kernel/tracing/events/syscalls/sys_enter_write/format
> name: sys_enter_write
> ID: 758
> 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;

Indeed, I see this new field __buf_val.

Steve, is this what you added recently for taking user contents?
Hmm.. this makes perf trace confused wrt the syscall parameters.
Is it always __buf_val or has any patterns?

> 
> print fmt: "fd: 0x%08lx, buf: 0x%08lx (%s), count: 0x%08lx", ((unsigned long)(REC->fd)), ((unsigned long)(REC->buf)), __print_dynamic_array(__buf_val, 1), ((unsigned long)(REC->count))
> bash-5.3# 
> 
> Hope this helps.

Yes it did, thanks!
Namhyung


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ