[lttng-dev] Scope of event names?

[Mathieu Desnoyers]

Hi Daniel,

Yep, it seems to be a discrepancy in the semantic of event name scope
uniqueness checks. Not sure if it comes from lttng-modules or
lttng-tools. For now, please file a bug report against lttng-tools on
the bug tracker.

Thanks,

Mathieu

* Thibault, Daniel (Daniel.Thibault at drdc-rddc.gc.ca) wrote:
>    I'm operating under the assumption that an event's "fully qualified" identifier is something like session:domain:channel:name.  Tracepoints and syscalls have system-defined names, and of course the domain can only be 'kernel' or 'userspace', but everything else is pretty much arbitrary.  My hypothesis is thus that, as long as they're in different channels (or domains or possibly sessions), two events may bear the same name even though they represent completely different occurrences.  So here's what I did (lttng list output has been abridged), with comments interspersed:
> 
> $ sudo -H lttng create asession
> Session asession created.
> Traces will be written in /root/lttng-traces/asession-20130214-145626
> $ sudo -H lttng enable-event sched_switch -k --tracepoint
> kernel event sched_switch created in channel channel0
> $ sudo -H lttng enable-event sched_switch -k --function lttng_calibrate_kretprobe --channel channel1
> Error: Event sched_switch: Enable kernel event failed (channel channel1, session asession)
> Warning: Some command(s) went wrong
> /*
>  Okay, so maybe event names have session:domain scope. Let's test this.
>  */
> $ sudo -H lttng enable-event fevent -k --function lttng_calibrate_kretprobe --channel channel1
> kernel event fevent created in channel channel1
> $ sudo -H lttng enable-event fevent -k --function lttng_calibrate_kretprobe --channel channel2
> kernel event fevent created in channel channel2
> /*
>  Apparently not.
>  */
> $ sudo -H lttng list asession
> Tracing session asession: [inactive]
> === Domain: Kernel ===
> - channel2: [enabled]
>     Events:
>       fevent (type: probe) [enabled]
>         offset: 0x0
>         symbol: lttng_calibrate_kretprobe
> - channel1: [enabled]
>     Events:
>       fevent (type: probe) [enabled]
>         offset: 0x0
>         symbol: lttng_calibrate_kretprobe
> - channel0: [enabled]
>     Events:
>       sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
> /*
>  Instead of tracepoint then function, let's try function then tracepoint
>  */
> $ sudo -H lttng enable-event sched_process_fork -k --function lttng_calibrate_kretprobe --channel channel3
> kernel event sched_process_fork created in channel channel3
> $ sudo -H lttng enable-event sched_process_fork -k
> kernel event sched_process_fork created in channel channel0
> $ sudo -H lttng enable-event sched_process_fork -k --function lttng_calibrate_kretprobe --channel channel4
> Error: Event sched_process_fork: Enable kernel event failed (channel channel4, session asession)
> Warning: Some command(s) went wrong
> /*
>  Fascinating.
>  */
> $ sudo -H lttng list asession
> Tracing session asession: [inactive]
> - channel3: [enabled]
>     Events:
>       sched_process_fork (type: probe) [enabled]
>         offset: 0x0
>         symbol: lttng_calibrate_kretprobe
> - channel2: [enabled]
>     Events:
>       fevent (type: probe) [enabled]
>         offset: 0x0
>         symbol: lttng_calibrate_kretprobe
> - channel1: [enabled]
>     Events:
>       fevent (type: probe) [enabled]
>         offset: 0x0
>         symbol: lttng_calibrate_kretprobe
> - channel0: [enabled]
>     Events:
>       sched_process_fork (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
>       sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
> 
>    At this point it looks like defining a kernel tracepoint prevents that tracepoint's name from being used in other channels to define other events (or even the same event).  But nothing apparently prevents these other events from being set up *before* the tracepoint.  (Not shown here is the case where a tracepoint is defined in one channel, and then in another: the second tracepoint event definition fails as well)
> 
>    Can anyone shed light on this?  (Note that I haven't even tried yet to see what happens between simultaneous sessions...)
> 
>    The control flow of the error-causing commands is something like:
> 
> event.c's event_kernel_enable_tracepoint returns LTTNG_ERR_KERN_ENABLE_FAIL because
> kernel.c's kernel_create_event gets something else than ENOSYS or EEXIST from
> kernel-ctl.c's kernctl_create_event 
> 
>    Beyond kernctl_create_event is debugfs, inside of which occurs...whatever.
> 
> Daniel U. Thibault
> R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
> Cyber sécurité pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
> Protection des systèmes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
> 2459 route de la Bravoure
> Québec, QC  G3J 1X5
> CANADA
> Vox : (418) 844-4000 x4245
> Fax : (418) 844-4538
> NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
> Gouvernement du Canada / Government of Canada
> <http://www.valcartier.drdc-rddc.gc.ca/>
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com