* traceevent support for kernels with CONFIG_GCC_PLUGIN_STRUCTLEAK=y
@ 2019-12-12 17:07 John Koepi
2019-12-12 17:25 ` Steven Rostedt
0 siblings, 1 reply; 6+ messages in thread
From: John Koepi @ 2019-12-12 17:07 UTC (permalink / raw)
To: linux-trace-devel; +Cc: rostedt, tz.stoyanov
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: traceevent support for kernels with CONFIG_GCC_PLUGIN_STRUCTLEAK=y
2019-12-12 17:07 traceevent support for kernels with CONFIG_GCC_PLUGIN_STRUCTLEAK=y John Koepi
@ 2019-12-12 17:25 ` Steven Rostedt
2019-12-14 15:38 ` John Koepi
0 siblings, 1 reply; 6+ messages in thread
From: Steven Rostedt @ 2019-12-12 17:25 UTC (permalink / raw)
To: John Koepi; +Cc: linux-trace-devel, tz.stoyanov
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: traceevent support for kernels with CONFIG_GCC_PLUGIN_STRUCTLEAK=y
2019-12-12 17:25 ` Steven Rostedt
@ 2019-12-14 15:38 ` John Koepi
2020-01-15 18:06 ` [PATCH bpf] traceevent: ignore __attribute__ in fields format Ivan Prisyazhnyy
0 siblings, 1 reply; 6+ messages in thread
From: John Koepi @ 2019-12-14 15:38 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-trace-devel, tz.stoyanov
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH bpf] traceevent: ignore __attribute__ in fields format
2019-12-14 15:38 ` John Koepi
@ 2020-01-15 18:06 ` Ivan Prisyazhnyy
2020-01-15 18:47 ` John Koepi
0 siblings, 1 reply; 6+ messages in thread
From: Ivan Prisyazhnyy @ 2020-01-15 18:06 UTC (permalink / raw)
To: linux-trace-devel
Cc: Steven Rostedt, Alexei Starovoitov, Daniel Borkmann, Ivan Prisyazhnyy
To support kernel (e.g. Arch linux) tracing that
have events fields with C attributes (__attribute__((xxx))),
traceevent must ignore __attribute__ parts when
parsing fields types.
An example from Arch linux kernel 4.2:
$ cat /sys/kernel/.../sys_enter_io_submit/format
...
field:struct iocb __attribute__((user)) * ...
^^^
This fix adds support for fields types C attributes
parsing to event_read_fields function. When it sees
__attribute__ ((attribute-list)) expression it skips
it.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=205857
Base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/
Signed-off-by: Ivan Prisyazhnyy <john.koepi@gmail.com>
---
tools/lib/traceevent/event-parse.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
index beaa8b8c08ff..fbc1ea536742 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -1486,6 +1486,28 @@ static int event_read_fields(struct tep_event *event, struct tep_format_field **
(event->flags & TEP_EVENT_FL_ISFTRACE &&
type == TEP_EVENT_OP && strcmp(token, ".") == 0)) {
+ /* ignore C attributes: __attribute__((expr)) */
+ if (strcmp(token, "__attribute__") == 0) {
+ free(token);
+ for (int i = 0; i < 2; i++) {
+ if (read_expected_item(TEP_EVENT_DELIM, "(") < 0) {
+ goto fail_expect;
+ }
+ }
+ for (int brackets = 2; brackets > 0;) {
+ if (read_token(&token) == TEP_EVENT_NONE) {
+ do_warning_event(event, "%s: __attribute__ not full", __func__);
+ goto fail_expect;
+ }
+ if (strcmp(token, "(") == 0)
+ brackets++;
+ else if (strcmp(token, ")") == 0)
+ brackets--;
+ free(token);
+ }
+ continue;
+ }
+
if (strcmp(token, "*") == 0)
field->flags |= TEP_FIELD_IS_POINTER;
--
2.24.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH bpf] traceevent: ignore __attribute__ in fields format
2020-01-15 18:06 ` [PATCH bpf] traceevent: ignore __attribute__ in fields format Ivan Prisyazhnyy
@ 2020-01-15 18:47 ` John Koepi
2020-01-15 19:31 ` Steven Rostedt
0 siblings, 1 reply; 6+ messages in thread
From: John Koepi @ 2020-01-15 18:47 UTC (permalink / raw)
To: linux-trace-devel; +Cc: Steven Rostedt, Alexei Starovoitov, Daniel Borkmann
I am not sure this is the right mailing list (I was not sure about
@netdev). If it is not - I am sorry, I can resend it. The test for
this change is at https://github.com/sitano/traceevent_attribute.
On Wed, Jan 15, 2020 at 8:06 PM Ivan Prisyazhnyy <john.koepi@gmail.com> wrote:
>
> To support kernel (e.g. Arch linux) tracing that
> have events fields with C attributes (__attribute__((xxx))),
> traceevent must ignore __attribute__ parts when
> parsing fields types.
>
> An example from Arch linux kernel 4.2:
>
> $ cat /sys/kernel/.../sys_enter_io_submit/format
> ...
> field:struct iocb __attribute__((user)) * ...
> ^^^
>
> This fix adds support for fields types C attributes
> parsing to event_read_fields function. When it sees
> __attribute__ ((attribute-list)) expression it skips
> it.
>
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=205857
> Base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/
> Signed-off-by: Ivan Prisyazhnyy <john.koepi@gmail.com>
> ---
> tools/lib/traceevent/event-parse.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
> index beaa8b8c08ff..fbc1ea536742 100644
> --- a/tools/lib/traceevent/event-parse.c
> +++ b/tools/lib/traceevent/event-parse.c
> @@ -1486,6 +1486,28 @@ static int event_read_fields(struct tep_event *event, struct tep_format_field **
> (event->flags & TEP_EVENT_FL_ISFTRACE &&
> type == TEP_EVENT_OP && strcmp(token, ".") == 0)) {
>
> + /* ignore C attributes: __attribute__((expr)) */
> + if (strcmp(token, "__attribute__") == 0) {
> + free(token);
> + for (int i = 0; i < 2; i++) {
> + if (read_expected_item(TEP_EVENT_DELIM, "(") < 0) {
> + goto fail_expect;
> + }
> + }
> + for (int brackets = 2; brackets > 0;) {
> + if (read_token(&token) == TEP_EVENT_NONE) {
> + do_warning_event(event, "%s: __attribute__ not full", __func__);
> + goto fail_expect;
> + }
> + if (strcmp(token, "(") == 0)
> + brackets++;
> + else if (strcmp(token, ")") == 0)
> + brackets--;
> + free(token);
> + }
> + continue;
> + }
> +
> if (strcmp(token, "*") == 0)
> field->flags |= TEP_FIELD_IS_POINTER;
>
> --
> 2.24.1
>
--
-- Ivan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-15 19:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-12 17:07 traceevent support for kernels with CONFIG_GCC_PLUGIN_STRUCTLEAK=y John Koepi
2019-12-12 17:25 ` Steven Rostedt
2019-12-14 15:38 ` John Koepi
2020-01-15 18:06 ` [PATCH bpf] traceevent: ignore __attribute__ in fields format Ivan Prisyazhnyy
2020-01-15 18:47 ` John Koepi
2020-01-15 19:31 ` Steven Rostedt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).