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 ([email protected]) 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 > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
