Re: [PATCH] perf trace: Skip internal syscall arguments

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 26 Nov 2025 20:44:18 -0800
Namhyung Kim <namhyung@kernel.org> wrote:

> Recent changes in the linux-next kernel will add new field for syscalls
> to have contents in the userspace like below.
> 
>   # 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;
> 
>   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))
> 
> We have a different way to handle those arguments and this change
> confuses perf trace then make some tests failing.  Fix it by skipping
> the new fields that have "__data_loc char[]" type.
> 
> Maybe we can switch to this instead of the BPF augmentation later.
> 

Even with this patch applied, I still have a segfault with this command:

# ./perf trace -e syscalls:sys_enter_write 
     0.000 sshd-session/5421 syscalls:sys_enter_write(perf: Segmentation fault
    #0 0x560ea815187a in dump_stack debug.c:366
    #1 0x560ea81518f0 in sighandler_dump_stack debug.c:378
    #2 0x7fb5e14d1df0 in __restore_rt libc_sigaction.c:0
    #3 0x560ea7fc0cec in syscall_arg__scnprintf_buf builtin-trace.c:1857
    #4 0x560ea7fc2692 in syscall_arg_fmt__scnprintf_val builtin-trace.c:2398
    #5 0x560ea7fc2aad in syscall__scnprintf_args builtin-trace.c:2476
    #6 0x560ea7fc3ea2 in trace__fprintf_sys_enter builtin-trace.c:2885
    #7 0x560ea7fc57a5 in trace__event_handler builtin-trace.c:3312
    #8 0x560ea7fc68dd in trace__handle_event builtin-trace.c:3649
    #9 0x560ea7fc7f7a in __trace__deliver_event builtin-trace.c:4183
    #10 0x560ea7fc80cc in trace__deliver_event builtin-trace.c:4209
    #11 0x560ea7fc92b7 in trace__run builtin-trace.c:4577
    #12 0x560ea7fcd648 in cmd_trace builtin-trace.c:5773
    #13 0x560ea7fd35e3 in run_builtin perf.c:349
    #14 0x560ea7fd387b in handle_internal_command perf.c:401
    #15 0x560ea7fd39d4 in run_argv perf.c:448
    #16 0x560ea7fd3d1d in main perf.c:555
    #17 0x7fb5e14bbca8 in __libc_start_call_main libc_start_call_main.h:74
    #18 0x7fb5e14bbd65 in __libc_start_main@@GLIBC_2.34 libc-start.c:128
    #19 0x560ea7f25f41 in _start perf[53f41]
Segmentation fault

This doesn't crash in a kernel without the __data_loc.

-- Steve