Kernel event name shadowing can break syscall tracing
The kernel domain currently operates under the restriction that an event (as identified by its name alone) can only be assigned once. This can lead to event name shadowing: if you use a known kernel tracepoint name (such as
sched_switch, for example) to label a kernel event of a different type (
--function), you will not be able to enable or disable the kernel tracepoint, nor will you be able to assign it to any channel, even with the
--all option. Fair enough.
The situation is considerably worse with the system call names, however: if you use any system call name (e.g.
sys_sched_yield, etc.), including the LTTng-reserved names
exit_syscall for a
--function event, ('
lttng enable-event -k --syscall --all' will yield the “Events: Enable kernel event failed” error message). (Interestingly,
sys_enter is okay to use)
Aside: The reverse is not as bad. If you enable system calls, you can no longer use any system call name for
--function events. The only thing bad about this is the rather uninformative error message (“Events: Enable kernel event failed” again).
I'm not sure how this 'bug' should be dealt with. Clearly, checking the user's proposed name against the existing system call names (nearly 300 of them) would be too expensive an operation. A cheap fix would be to ban the
--function events from using names matching either
Using the lttng 2.3.0 suite.
Updated by David Goulet over 6 years ago
- Status changed from New to Feedback
- Target version changed from 2.4 to 2.3
This example works for me on 2.3 and 2.4:
- lttng enable-event -k test --probe sys_open
- lttng enable-event -a -k --syscall
- lttng enable-event -k test2 --probe sys_close
Is this triggering the error for you? Am I understanding this correctly?
Updated by Daniel U. Thibault over 6 years ago
The problem does not lie in hooking up multiple events at the same spot (in your example, the sys_open tracepoint). It lies in using a system call name for a non-syscall event.
This first example shows how using a system call name for a non-syscall event breaks later syscall tracing (even in a different channel):
$ lttng create test9 Session test9 created. Traces will be written in /home/daniel/lttng-traces/test9-20131105-170337 $ lttng enable-event sys_unknown --probe sys_open -k kernel event sys_unknown created in channel channel0 $ lttng disable-event sys_unknown -k kernel event sys_unknown disabled in channel channel0 for session test9 $ lttng enable-event --syscall -k -a Error: Events: Enable kernel event failed (channel channel0, session test9) $ lttng destroy -a
Here's another example showing that you cannot use system call names for other events once syscall tracing has been enabled (the lesser bug, again even in another channel altogether):
$ lttng create testa Session testa created. Traces will be written in /home/daniel/lttng-traces/testa-20131105-170434 $ lttng enable-event --syscall -k -a All kernel system calls are enabled in channel channel0 $ lttng disable-channel -k channel0 Kernel channel channel0 disabled for session testa $ lttng enable-channel -k channel1 Kernel channel channel1 enabled for session testa $ lttng enable-event sys_unknown --probe sys_open -k -c channel1 Error: Event sys_unknown: Enable kernel event failed (channel channel1, session testa) Warning: Some command(s) went wrong $ lttng destroy -a
Going back to the first example, we verify that everything works okay as long as we use a non-system call name for our "other event":
$ lttng create testb Session testb created. Traces will be written in /home/daniel/lttng-traces/testb-20131112-123456 $ lttng enable-event sys_unkn0wn --probe sys_open -k kernel event sys_unkn0wn created in channel channel0 $ lttng enable-event --syscall -k -a All kernel system calls are enabled in channel channel0 $ lttng destroy -a
It seems LTTng reserves explicit names for all system calls (including
exit_syscall). The difference being that the actual name reservations cannot be shown to the user by the
list command, either beforehand or after syscall tracing is enabled.
Updated by Mathieu Desnoyers about 6 years ago
- Status changed from Confirmed to Resolved
commit abc0446a8da1fe7cc09a546389cbcc932b265520 Author: Mathieu Desnoyers <email@example.com> Date: Wed Jan 15 12:37:25 2014 -0500 Fix: provide more precise error report for enable event Fixes #658 Signed-off-by: Mathieu Desnoyers <firstname.lastname@example.org>