lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 19 Jan 2008 10:29:39 -0500 From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> To: "Frank Ch. Eigler" <fche@...hat.com> Cc: Steven Rostedt <rostedt@...dmis.org>, LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Christoph Hellwig <hch@...radead.org>, Gregory Haskins <ghaskins@...ell.com>, Arnaldo Carvalho de Melo <acme@...stprotocols.net>, Thomas Gleixner <tglx@...utronix.de>, Tim Bird <tim.bird@...sony.com>, Sam Ravnborg <sam@...nborg.org>, Steven Rostedt <srostedt@...hat.com>, Paul Mackerras <paulus@...ba.org>, Daniel Walker <dwalker@...sta.com> Subject: Re: [RFC PATCH 16/22 -v2] add get_monotonic_cycles * Frank Ch. Eigler (fche@...hat.com) wrote: > Hi - > > On Fri, Jan 18, 2008 at 10:55:27PM -0500, Steven Rostedt wrote: > > [...] > > > All this complexity is to be justified by keeping the raw prev/next > > > pointers from being sent to a naive tracer? It seems to me way out of > > > proportion. > > > > Damn, and I just blew away all my marker code for something like this ;-) > > Sorry! :-) > > > [...] > > We have in sched.c the following marker: > > trace_mark(kernel_sched_scheduler, "prev %p next %p", prev, next); > > Fine so far! > > > Then Mathieu can add in some code somewhere (or a module, or something) > > ret = marker_probe_register("kernel_sched_scheduler", > > "prev %p next %p", > > pretty_print_sched_switch, NULL); > > > static void pretty_print_sched_switch(const struct marker *mdata, > > void *private_data, > > const char *format, ...) > > { > > [...] > > trace_mark(kernel_pretty_print_sched_switch, > > "prev_pid %d next_pid %d prev_state %ld", > > prev->pid, next->pid, prev->state); > > } > > That marker_probe_register call would need to be done only when the > embedded (k_p_p_s_s) marker is actually being used. Otherwise we'd > lose all the savings of a dormant sched.c marker by always calling > into pretty_print_sched_switch(), whether or not the k_p_p_s_s marker > was active. > > In any case, if the naive tracer agrees to become educated about some > of these markers in the form of intermediary functions like that, they > need not insist on a second hop through marker territory anyway: > > static void pretty_print_sched_switch(const struct marker *mdata, > void *private_data, > const char *format, ...) > { > [...] > lttng_backend_trace(kernel_pretty_print_sched_switch, > "prev_pid %d next_pid %d prev_state %ld", > prev->pid, next->pid, prev->state); > } > Oh! perfect then :) Since I already planned my ltt-marker-control kernel module to connect specialized callbacks instead of the dumb one, it shouldn't be so hard to do. I would just have to find another way to declare the trace events (it's currently embedded in the markers), but it's not a showstopper. I'll try this. Thanks to you both for the good proposals, Mathieu > > - FChE -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists