Filed at https://bugzilla.kernel.org/show_bug.cgi?id=205857 -- Ivan On Thu, Dec 12, 2019 at 7:25 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Thu, 12 Dec 2019 19:07:46 +0200 > John Koepi <john.koepi@xxxxxxxxx> wrote: > > > > $ 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? > > Thanks for the report. This looks like something we can have > libtraceveent handle, no need to change the kernel. > > Could you file a bug report? > > https://bugzilla.kernel.org/buglist.cgi?component=Trace-cmd%2FKernelshark&product=Tools&resolution=--- > > -- Steve >
|