linux-kernel - Re: [RFC v3][PATCH 0/2] Make ftrace able to trace function return

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]

Date:	Tue, 11 Nov 2008 18:14:55 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frédéric Weisbecker <fweisbec@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v3][PATCH 0/2] Make ftrace able to trace function return


* Frédéric Weisbecker <fweisbec@...il.com> wrote:

> >  2) i cleaned up the arch/x86/Kconfig impact:
> >
> >      f1c4be5: tracing, x86: clean up FUNCTION_RET_TRACER Kconfig
> 
> 
> Ok.
> And concerning the constraint fixed in assembly. That's strange my
> compiler didn't even warn me about it.

yep, that's common with assembly constraints - often the bugs will 
only trigger with certain compilers and with certain config options. 
Generally we've got enough variations of these parameters in -tip 
testing (randconfig plus multiple tools versions) to reliably trigger 
such issues.

> > So lets use "function_full" and "function" tracing perhaps? The 
> > "full" tracer is what traces both entry and exit points, and 
> > establishes full function-call timings/costs. The "function" 
> > tracer is more lightweight and traces function entry events.
> 
> Right. I first chose function_return but it was the largest tracer 
> name and so raised a bug that has been corrected since. And I kept 
> this confusing name.
>
> I'm not sure function_full is really the good one because it's not 
> really a full version of the function tracer. It doesn't do the same 
> thing: when you look into a trace done by the function tracer, the 
> functions appear in order of their call whereas with the function 
> return tracer, they appear in the order of their return which is not 
> the same. The effect is not the same. Why not function_return or 
> something like that?

at the risk of bikeshed-painting this issue too much, the problem with 
function_return is that it has little meaning to actual users and even 
to developers. What does the "return" mean? We know what it means, 
because we know that opposed to function entry we'll also capture 
function returns, and hence be able to do full function call tracing.

so function_full i thought to conduct this aspect of it better. But 
suggestions are welcome.

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