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] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0812030645370.29045@gandalf.stny.rr.com>
Date:	Wed, 3 Dec 2008 06:49:09 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 4/5] ftrace: function graph return for function entry


On Wed, 3 Dec 2008, Ingo Molnar wrote:

> 
> * Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > From: Steven Rostedt <srostedt@...hat.com>
> > 
> > Impact: feature, let entry function decide to trace or not
> > 
> > This patch lets the graph tracer entry function decide if the tracing 
> > should be done at the end as well. This requires all function graph 
> > entry functions return 1 if it should trace, or 0 if the return should 
> > not be traced.
> 
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index 47aa5f0..cef05a2 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -119,6 +119,9 @@ ENTRY(mcount)
> >  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> >  	cmpq $ftrace_stub, ftrace_graph_return
> >  	jnz ftrace_graph_caller
> > +
> > +	cmpq $ftrace_graph_entry_stub, ftrace_graph_entry
> > +	jnz ftrace_graph_caller
> 
> hm, that's in the hotpath. What's the point of this? Do we want some sort 
> of configuration vector that allows per function graphing versus 
> entry-only traces?

Actually, I'm fine with taking it out. But when we register a function 
graph, we register both a entry and exit. I would think it should still 
work if one was still set as the default. Unless we document it someplace 
that either the entry or exit must be set.

This change has the function graph work if one or the other is set to 
something other than the default.

Also, this is only in the static ftrace path, not dynamic, but then again, 
maybe that means it is even hotter.

I'm fine with pulling this out. It was not really needed, I was just 
trying to make it intuitive.

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