x86_64: could increment fp when getting wchan?

x86_64: could increment fp when getting wchan?

[Hillf Danton]

When getting wchan (wait channel?) the stack of given task is scanned
for IP that is not in the scheduling area. What looks odd is the IP
could be checked as many times as allowed in the loop without changing
the location on stack. Could the IP be checked up stair the stack?

Hillf
---

--- a/arch/x86/kernel/process_64.c	2011-01-05 08:50:20.000000000 +0800
+++ b/arch/x86/kernel/process_64.c	2011-01-21 21:46:04.000000000 +0800
@@ -543,7 +543,7 @@ unsigned long get_wchan(struct task_stru
 		ip = *(u64 *)(fp+8);
 		if (!in_sched_functions(ip))
 			return ip;
-		fp = *(u64 *)fp;
+		fp += 8;
 	} while (count++ < 16);
 	return 0;
 }

Re: x86_64: could increment fp when getting wchan?

[Thomas Gleixner]

On Fri, 21 Jan 2011, Hillf Danton wrote:

> When getting wchan (wait channel?) the stack of given task is scanned
> for IP that is not in the scheduling area. What looks odd is the IP
> could be checked as many times as allowed in the loop without changing
> the location on stack. Could the IP be checked up stair the stack?

Errm.
 
> Hillf
> ---
> 
> --- a/arch/x86/kernel/process_64.c	2011-01-05 08:50:20.000000000 +0800
> +++ b/arch/x86/kernel/process_64.c	2011-01-21 21:46:04.000000000 +0800
> @@ -543,7 +543,7 @@ unsigned long get_wchan(struct task_stru
>  		ip = *(u64 *)(fp+8);

IP (Return address) is read from stack via fp (Frame pointer)

>  		if (!in_sched_functions(ip))
>  			return ip;
> -		fp = *(u64 *)fp;

Now fp is set to the next stack frame, so the next loop will read a
different IP.

> +		fp += 8;
>  	} while (count++ < 16);
>  	return 0;
>  }

Thanks,

	tglx