Re: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME_POINTER friendly

[Frederic Weisbecker <fweisbec@gmail.com>]

On Thu, Jun 03, 2010 at 12:53:52PM -0700, Arjan van de Ven wrote:
> On 6/3/2010 12:32 PM, Oleg Nesterov wrote:
>> If CONFIG_FRAME_POINTER=n, print_context_stack() shouldn't neglect the
>> non-reliable addresses on stack, this is all we have if dump_trace(bp)
>> is called with the wrong or zero bp.
>>
>> For example, /proc/pid/stack doesn't work if CONFIG_FRAME_POINTER=n.
>>
>> This patch obviously has no effect if CONFIG_FRAME_POINTER=y, otherwise
>> it reverts 1650743c "x86: don't save unreliable stack trace entries".
>>    
>
> would be nice if there was a compile time thing to detect if frame  
> pointers are on ratehr than an ifdef.


I wanted to suggest that too, but since only one place got the ifdef
after the second patch.

But yeah, something like this could be reused:


	if (reliable_frame_pointer(reliable))
		return ...;



> you're now also changing the rules; until now, you would ALWAYS get a  
> backtrace without noise....
> now that's changing quite a bit. How are various tools (like perf and  
> sysprof) going to cope with that?



perf and sysprof have their own stacktrace ops, so they aren't affected.
I think the rest is /proc/pid/task, lockdep, latencytop, ftrace, kmemleak,
etc...

For the kernel parts it's in fact desired.
And with ftrace we are changing some rules, but this is desired too, without
frame pointers we would have nothing anyway. And it's quite easy to
find out a stacktrace is not entirely reliable at a glance.