linux-kernel - Re: tracing: confusing output of function_graph when notrace function calls traceable function

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, 6 Jan 2010 10:15:32 -0800
From:	Tim Bird <tim.bird@...sony.com>
To:	"rostedt@...dmis.org" <rostedt@...dmis.org>
CC:	Jiri Olsa <jolsa@...hat.com>, Lai Jiangshan <laijs@...fujitsu.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: tracing: confusing output of function_graph when notrace function
 calls traceable function

>Steven Rostedt wrote:
>>On Wed, 2010-01-06 at 14:08 +0100, Jiri Olsa wrote:
>>> On Wed, Jan 06, 2010 at 06:44:02PM +0800, Lai Jiangshan wrote:
>>> == real graph ==:
>>>
>>> father_fun()
>>>   child_fun()
>>>   notrace_child_fun()
>>>     grandchild_fun1()
>>>     grandchild_fun2()
>>>
>>> ===function_graph shows===>
>>>
>>> father_fun()
>>>   child_fun()
>>>   grandchild_fun1()
>>>   grandchild_fun2()
>>>
>>> When the notrace function calls traceable function, function_graph will
>>> get wrong depth of functions, and show wrong graph.
>>>
>>> Is there any method to fix it?
>> I dont think so..
>>
>> AFAIK the depth computation is based on the traced functions, and there's
>> no other 'depth related' input apart from them.
> 
> Right.
> 
> 
> Honestly, if you think about it, the "father_fun()" does call those
> grandchild_fun() functions. Just indirectly. I don't find anything wrong
> with this.
> 
> You get the same issue if gcc decides to inline a function, since those
> inlined functions don't get traced either.

Well, there is at least one thing different that could be used to indicate
that we're "down" farther in the call nesting, and that is stack depth.
In the example above, grandchild_fun1() is going to have a lower stack position
than child_fun().  So you might be able to use 'sp' to distinguish between
children and lower descendents.

You could potentially use this as an indicator for increased
indentation, but I'm not sure how accurate it is.
This might be different from the inline case, where the compiler usually
does not build a stack frame for the "called" code.  But you also might
get false positives from variables declared inside in-function blocks
(or from other compiler oddities).

I would lean towards Steve's answer, that it doesn't matter too much.
Invisibility in the trace log, and the possible confusion it creates,
is the price you pay for 'notrace'.

Just my 2 cents.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

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