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

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

[Oleg Nesterov]

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

Also, remove the unnecessary type-cast.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---

 arch/x86/kernel/stacktrace.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- 34-rc1/arch/x86/kernel/stacktrace.c~SAVE_STACK_WO_FP	2010-06-03 18:43:27.000000000 +0200
+++ 34-rc1/arch/x86/kernel/stacktrace.c	2010-06-03 21:29:52.000000000 +0200
@@ -26,8 +26,10 @@ static int save_stack_stack(void *data, 
 static void save_stack_address(void *data, unsigned long addr, int reliable)
 {
 	struct stack_trace *trace = data;
+#ifdef CONFIG_FRAME_POINTER
 	if (!reliable)
 		return;
+#endif
 	if (trace->skip > 0) {
 		trace->skip--;
 		return;
@@ -39,9 +41,11 @@ static void save_stack_address(void *dat
 static void
 save_stack_address_nosched(void *data, unsigned long addr, int reliable)
 {
-	struct stack_trace *trace = (struct stack_trace *)data;
+	struct stack_trace *trace = data;
+#ifdef CONFIG_FRAME_POINTER
 	if (!reliable)
 		return;
+#endif
 	if (in_sched_functions(addr))
 		return;
 	if (trace->skip > 0) {

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

[Frederic Weisbecker]

On Thu, Jun 03, 2010 at 09:32:39PM +0200, 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".
> 
> Also, remove the unnecessary type-cast.
> 
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>


Acked-by: Frederic Weisbecker <fweisbec@gmail.com>

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

[Arjan van de Ven]

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.

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?

> Also, remove the unnecessary type-cast.
>
> Signed-off-by: Oleg Nesterov<oleg@redhat.com>
> ---
>
>   arch/x86/kernel/stacktrace.c |    6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> --- 34-rc1/arch/x86/kernel/stacktrace.c~SAVE_STACK_WO_FP	2010-06-03 18:43:27.000000000 +0200
> +++ 34-rc1/arch/x86/kernel/stacktrace.c	2010-06-03 21:29:52.000000000 +0200
> @@ -26,8 +26,10 @@ static int save_stack_stack(void *data,
>   static void save_stack_address(void *data, unsigned long addr, int reliable)
>   {
>   	struct stack_trace *trace = data;
> +#ifdef CONFIG_FRAME_POINTER
>   	if (!reliable)
>   		return;
> +#endif
>   	if (trace->skip>  0) {
>   		trace->skip--;
>   		return;
> @@ -39,9 +41,11 @@ static void save_stack_address(void *dat
>   static void
>   save_stack_address_nosched(void *data, unsigned long addr, int reliable)
>   {
> -	struct stack_trace *trace = (struct stack_trace *)data;
> +	struct stack_trace *trace = data;
> +#ifdef CONFIG_FRAME_POINTER
>   	if (!reliable)
>   		return;
> +#endif
>   	if (in_sched_functions(addr))
>   		return;
>   	if (trace->skip>  0) {
>
>    

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

[Frederic Weisbecker]

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.

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

[Oleg Nesterov]

On 06/03, Frederic Weisbecker wrote:
>
> 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 ...;

Do you mean it makes sense to add the helper which depends on
FRAME_POINTER ?

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

Frederic, Arjan. Honestly, I have no opinion if this change makes
things better or worse for, say, lockdep.

But note that this only affects the !CONFIG_FRAME_POINTER case.
Looking into Kconfig's I don't even understand how the bug reporters
managed to set CONFIG_STACKTRACE without !CONFIG_FRAME_POINTER.

So, should I redo this patch to fix /proc/pid/stack ? Say, we
can change the meaning of stack_trace-<skip, if it is < 0, then
save_stack_address() ignores reliable. Yes, this is hack.

Oleg.

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

[Frederic Weisbecker]

On Thu, Jun 03, 2010 at 10:31:55PM +0200, Oleg Nesterov wrote:
> On 06/03, Frederic Weisbecker wrote:
> >
> > 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 ...;
> 
> Do you mean it makes sense to add the helper which depends on
> FRAME_POINTER ?



Having in asm/stacktrace.h:

#ifdef CONFIG_FRAME_POINTER
static inline int reliable_frame_pointer(int reliable)
{
	return reliable;
}
#else
static inline int reliable_frame_pointer(int reliable)
{
	return 1;
}
#endif


But if we have only one user I'm not sure it's worth it.


 
> > > 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.
> 
> Frederic, Arjan. Honestly, I have no opinion if this change makes
> things better or worse for, say, lockdep.
> 
> But note that this only affects the !CONFIG_FRAME_POINTER case.
> Looking into Kconfig's I don't even understand how the bug reporters
> managed to set CONFIG_STACKTRACE without !CONFIG_FRAME_POINTER.
> 
> So, should I redo this patch to fix /proc/pid/stack ? Say, we
> can change the meaning of stack_trace-<skip, if it is < 0, then
> save_stack_address() ignores reliable. Yes, this is hack.


No, people may want to ignore reliable and also to skip
entries.

I think your patches as is are the right way to go: by default provide
as much information as we can.

And those who care about reliability can use their own stack ops, which
is what perf does for example. If needed we can still add a new
save_stack_trace_reliable() in the future.

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

[Oleg Nesterov]

On 06/03, Frederic Weisbecker wrote:
>
> On Thu, Jun 03, 2010 at 10:31:55PM +0200, Oleg Nesterov wrote:
> >
> > Do you mean it makes sense to add the helper which depends on
> > FRAME_POINTER ?
>
> Having in asm/stacktrace.h:
>
> #ifdef CONFIG_FRAME_POINTER
> static inline int reliable_frame_pointer(int reliable)
> {
> 	return reliable;
> }
> #else
> static inline int reliable_frame_pointer(int reliable)
> {
> 	return 1;
> }
> #endif
>
> But if we have only one user I'm not sure it's worth it.

Me too ;) let's ignore this.

> > Frederic, Arjan. Honestly, I have no opinion if this change makes
> > things better or worse for, say, lockdep.
> >
> > But note that this only affects the !CONFIG_FRAME_POINTER case.
> > Looking into Kconfig's I don't even understand how the bug reporters
> > managed to set CONFIG_STACKTRACE without !CONFIG_FRAME_POINTER.
> >
> > So, should I redo this patch to fix /proc/pid/stack ? Say, we
> > can change the meaning of stack_trace-<skip, if it is < 0, then
> > save_stack_address() ignores reliable. Yes, this is hack.
>
>
> No, people may want to ignore reliable and also to skip
> entries.

Yes, but currently stack_trace->skip is always >= 0. So I think
this should work

	skip  > 0 	- skip that much entries, consider reliable
	skip == 0	- don't skip, consider reliable
	skip  < 0	- skip nothing

But yes, I do not like this idea too much. I was going to use this
hack if this patch is nacked.

> I think your patches as is are the right way to go: by default provide
> as much information as we can.
>
> And those who care about reliability can use their own stack ops, which
> is what perf does for example. If needed we can still add a new
> save_stack_trace_reliable() in the future.

Great. Thanks!

Oleg.

[tip:perf/core] x86: Make save_stack_address() !CONFIG_FRAME_POINTER friendly

[tip-bot for Oleg Nesterov]

Commit-ID:  147ec4d2361e355ab32499f739cc24845ceb89da
Gitweb:     http://git.kernel.org/tip/147ec4d2361e355ab32499f739cc24845ceb89da
Author:     Oleg Nesterov <oleg@redhat.com>
AuthorDate: Thu, 3 Jun 2010 21:32:39 +0200
Committer:  Frederic Weisbecker <fweisbec@gmail.com>
CommitDate: Wed, 9 Jun 2010 17:32:15 +0200

x86: Make save_stack_address() !CONFIG_FRAME_POINTER friendly

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

Also, remove the unnecessary type-cast.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <20100603193239.GA31530@redhat.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
 arch/x86/kernel/stacktrace.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index ea54d02..abc321d 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -26,8 +26,10 @@ static int save_stack_stack(void *data, char *name)
 static void save_stack_address(void *data, unsigned long addr, int reliable)
 {
 	struct stack_trace *trace = data;
+#ifdef CONFIG_FRAME_POINTER
 	if (!reliable)
 		return;
+#endif
 	if (trace->skip > 0) {
 		trace->skip--;
 		return;
@@ -39,9 +41,11 @@ static void save_stack_address(void *data, unsigned long addr, int reliable)
 static void
 save_stack_address_nosched(void *data, unsigned long addr, int reliable)
 {
-	struct stack_trace *trace = (struct stack_trace *)data;
+	struct stack_trace *trace = data;
+#ifdef CONFIG_FRAME_POINTER
 	if (!reliable)
 		return;
+#endif
 	if (in_sched_functions(addr))
 		return;
 	if (trace->skip > 0) {