Re: traceevent support for kernels with CONFIG_GCC_PLUGIN_STRUCTLEAK=y

[John Koepi <john.koepi@gmail.com>]

Filed at https://bugzilla.kernel.org/show_bug.cgi?id=205857

-- Ivan

On Thu, Dec 12, 2019 at 7:25 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 12 Dec 2019 19:07:46 +0200
> John Koepi <john.koepi@gmail.com> 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
>