linux-kernel - Re: [RFC PATCH 16/22 -v2] add get_monotonic

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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/