Hi! In kernels built with CONFIG_GCC_PLUGIN_STRUCTLEAK=y definition of macros __user differs from the usual one: If __CHECKER__ is false: > # ifdef STRUCTLEAK_PLUGIN > # define __user __attribute__((user)) > # else > # define __user > # endif at linux-5.4.2-arch1/include/linux/compiler_types.h:28. It seems that this fact leads the syscalls definitions macros linux-5.4.2-arch1/include/linux/syscalls.h > 214:#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__) > 198:#define SYSCALL_METADATA(sname, nb, ...) > 135:#define SYSCALL_TRACE_ENTER_EVENT(sname) to include GGC attributes extensions definitions into the syscalls format metadata that is then delivered to the tracefs/syscalls/format. This gets syscalls formats to have __attribute__ inside: > $ cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_io_submit/format > name: sys_enter_io_submit > ID: 897 > format: > field:unsigned short common_type; offset:0; size:2; signed:0; > ... > field:struct iocb __attribute__((user)) * __attribute__((user)) * iocbpp; offset:32; size:8; signed:0; > ... Having __attribute__ leaked into syscalls format, it makes its impossible for the traceevent lib from the kernel/tools/lib to parse such fields, like in the example above. This in its turn makes it impossible to use tracing for those syscalls: > $ sudo perf record -e syscalls:sys_enter_io_submit -aR > libtraceevent: No such file or directory > Error: expected type 4 but read 5 Thus, tracing does not work for some syscalls in Arch Linux kernels. And I suppose for all kernels that built with structleak plugin support. Reproduce: https://github.com/sitano/traceevent_attribute My question: Is it a bug that the traceevent lib does not support parsing __attribute__ in syscalls formats? or it is a bug of the SYSCALL_DEFINEx macroses / build system that they do allow C attributes to leak? maybe this is already fixed in the latest kernel? or maybe I am missing something? Thx, Ivan
|