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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1269875347.19685.4492.camel@gandalf.stny.rr.com>
Date:	Mon, 29 Mar 2010 11:09:07 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCHv3 0/2] tracing: function graph output for
 preempt/irqs-off tracers

On Mon, 2010-03-29 at 13:17 +0200, Jiri Olsa wrote:

> >  # echo 0 > /debug/tracing/tracing_enabled
> >  # echo 0 > /debug/tracing/option/display-graph
> >  # cat /debug/tracing/trace
> > 
> > # tracer: irqsoff
> > irqbalan-2672    0d..2.   55us+: Unknown type 13
> > irqbalan-2672    0d.h2.   62us+: Unknown type 13
> 
> I forgot the max_tr buffer is actually the one displayed,
> so it needs reset as well when the display-graph option
> is switched on/off.

No! That breaks the rules. It should still show the contents of the
buffer even if we disable the trace or option.


> > I think you can still do the "event" part, without effecting the way the
> > function graph outputs normally. I would not have given up on that
> > method.  You don't need to worry about it processing other events,
> > because when you register it to write as an event, it will only be
> > called when a function graph event was found. It will not be processing
> > other events. Only when the tracer itself overrides the default writing
> > will it do so.
> 
> The events would be called only for TRACE_GRAPH_RET, TRACE_GRAPH_ENT entries and
> not for others, thats right.
> 
> However it's the graph ouput code that outputs other events' text
> within "/*" and "*/".
> 
> So using the event way, all other events would be printed as normal
> events(standard lines not alligned) with the standard header...
> not like comments, as they are in the function_graph tracer.
> 
> I thought it'd be good for graph output to stay the same in irqsoff
> tracer as in function_graph tracer.. if that is not the concern
> the event way would be probably nicer :)

It is, but you missed my point.

> 
> I'm sending updated patchset with above 2 fixies right away,
> I can do/resend the event way later if needed.

What I'm saying is that we should have _both_!  The event way (when the
option is disabled) and the current way when it is not. That is, if the
option is enabled, then the function graph can report all the data the
way it was. If the option is disabled, don't reset it, but have an
"event" print of the trace as well.

Understand what I'm trying to ask?

-- Steve


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