Linux-Trace-Devel Archive on
 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


In kernels built with CONFIG_GCC_PLUGIN_STRUCTLEAK=y
definition of macros __user differs from the usual one:

If __CHECKER__ is false:

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

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


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


^ 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

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-trace-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone