Linux-Trace-Devel Archive on lore.kernel.org
 help / color / Atom feed
* 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	[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

* Re: [PATCH bpf] traceevent: ignore __attribute__ in fields format
  2020-01-15 18:47       ` John Koepi
@ 2020-01-15 19:31         ` Steven Rostedt
  0 siblings, 0 replies; 6+ messages in thread
From: Steven Rostedt @ 2020-01-15 19:31 UTC (permalink / raw)
  To: John Koepi; +Cc: linux-trace-devel, Alexei Starovoitov, Daniel Borkmann

On Wed, 15 Jan 2020 20:47:47 +0200
John Koepi <john.koepi@gmail.com> wrote:

> 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.
> 

It's fine to send it here. It's in my queue to look at.

Thanks!

-- Steve


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

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

Linux-Trace-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-trace-devel/0 linux-trace-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-trace-devel linux-trace-devel/ https://lore.kernel.org/linux-trace-devel \
		linux-trace-devel@vger.kernel.org
	public-inbox-index linux-trace-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-trace-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git