linux-kernel - Re: [PATCH 4/5] ftrace: function graph return for function entry

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: <c62985530812030519r5698f3e9gd0e7d0f580c0140@mail.gmail.com>
Date:	Wed, 3 Dec 2008 14:19:32 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Steven Rostedt" <srostedt@...hat.com>
Subject: Re: [PATCH 4/5] ftrace: function graph return for function entry

2008/12/3 Steven Rostedt <rostedt@...dmis.org>:
>
> 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.


I like it that way too. One should choose wether setting a callback on
entry or return or both.
But it makes sense for me that should work with only one...

...unless. Actually setting only a callback on entry shoud better been
done from the ftrace-function-tracer.

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