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  linux-cve-announce  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:	Wed, 31 Mar 2010 12:36:54 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCHv3 0/2] tracing: function graph output for
 preempt/irqs-off tracers

On Wed, Mar 31, 2010 at 10:01:57AM +0200, Frederic Weisbecker wrote:
> On Wed, Mar 31, 2010 at 09:37:38AM +0200, Jiri Olsa wrote:
> > On Mon, Mar 29, 2010 at 11:41:39AM -0400, Steven Rostedt wrote:
> > > On Mon, 2010-03-29 at 17:21 +0200, Jiri Olsa wrote:
> > > 
> > > > > Understand what I'm trying to ask?
> > > > 
> > > > ok, so what you mean is:
> > > > - dont clear the max_tr and 
> > > > - add function graph events.
> > > > 
> > > > So when the tracing_enabled and display-graph are disabled we will
> > > > get events output rather than 'unknown event' output... right?
> > > 
> > > Right, although when the display-graph is disabled, we lose the /* */
> > > but that's fine.
> > 
> > ok, I have it done, but found another issue..
> > 
> > It's the tracer_flags which governs the tracer output. As I'm using
> > the function_graph tracer output functions, they follow function_graph
> > tracer's flags settings..
> > 
> > My first idea was a change that would allow tracer using flags
> > of other tracers.. so, when enabling irqsoff tracer the function_graph
> > tracer's options would become available.
> > 
> > I made the patch but got to the set_flag function which can be overloaded
> > by tracer. So I'd need to remember the flags's tracer, and it does
> > not seem right.. :)
> > 
> > any ideas?
> > 
> > thanks,
> > jirka
> 
> 
> Hehe :)
> 
> I don't think we need such a feature. I doubt anybody
> is going to play with the options granularity of the function
> graph tracer there.
> 
> We should rather focus on what is useful to display for irqsoff
> tracing, which means we need every function graph options set except
> funcgraph-overrun that is only there to debug the tracer
> itself (I haven't tried it for a while BTW).
> 
> What you can do is to save the function graph tracer options
> when the irqsoff tracer starts, then overwrite them, and eventually
> restore the previous values when the irqsoff reset callback is called.
> 
> Or preferably...
> 
> Another solution, a bit more proper, is to sanitize a bit the function
> graph tracer printing helpers by pushing the options as a parameter to
> them.
> 
> So the function graph tracer can call them by passing the function graph
> tracer options, and the irqsoff tracer or any other tracer can call them
> with its own options.

ok, this one looks good :) thanks

jirka
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ