Project

General

Profile

Actions
Copy link

Bug #658

closed

Kernel event name shadowing can break syscall tracing

Added by Daniel U. Thibault about 11 years ago. Updated almost 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
LTTng - 2.3
Start date:
11/05/2013
Due date:
% Done:

0%

Estimated time:

Description

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 (--probe or --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_open, sys_sched_yield, etc.), including the LTTng-reserved names sys_unknown and exit_syscall for a --probe or --function event, you will no longer be able to enable system call tracing for that session, for any channel ('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 --probe or --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 --probe or --function events from using names matching either exit_syscall or sys_*.

Using the lttng 2.3.0 suite.

Actions
Copy link
 #1

Updated by David Goulet about 11 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:

  1. lttng enable-event -k test --probe sys_open
  2. lttng enable-event -a -k --syscall
  3. lttng enable-event -k test2 --probe sys_close

Is this triggering the error for you? Am I understanding this correctly?

Actions
Copy link
 #2

Updated by Daniel U. Thibault about 11 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 sys_unknown and 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.

Actions
Copy link
 #3

Updated by Daniel U. Thibault about 11 years ago

Addendum: The bug also occurs with the compat_* system calls.

Actions
Copy link
 #4

Updated by David Goulet almost 11 years ago

  • Status changed from Feedback to Confirmed
Actions
Copy link
 #5

Updated by Mathieu Desnoyers almost 11 years ago

  • Status changed from Confirmed to Resolved

Fixed by:

commit abc0446a8da1fe7cc09a546389cbcc932b265520
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.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 <mathieu.desnoyers@efficios.com>
Actions
Copy link

Also available in: Atom PDF