Subject: bug in get_wchan ...

From: Florian Lohoff <[email-masked]>
Date: Thu, 20 Apr 2000 18:25:22 +0200

Hi,
i had some loops on the annoying "bug in get_wchan" and after i hopefully
understood whats going on 

arch/mips/kernel/process.c

    196 unsigned long get_wchan(struct task_struct *p)
    197 {
    198         unsigned long schedule_frame;
    199         unsigned long pc;
    200 
    201         if (!p || p == current || p->state == TASK_RUNNING)
    202                 return 0;
    203 
    204         pc = thread_saved_pc(&p->thread);
    205         if (pc == (unsigned long) interruptible_sleep_on
    206             || pc == (unsigned long) sleep_on) {
    207                 schedule_frame = ((unsigned long *)p->thread.reg30)[9];
    208                 return ((unsigned long *)schedule_frame)[15];
    209         }
    210         if (pc == (unsigned long) interruptible_sleep_on_timeout
    211             || pc == (unsigned long) sleep_on_timeout) {
    212                 schedule_frame = ((unsigned long *)p->thread.reg30)[9];
    213                 return ((unsigned long *)schedule_frame)[16];
    214         }
    215         if (pc >= first_sched && pc < last_sched) {
    216                 printk(KERN_DEBUG "Bug in %s\n", __FUNCTION__);
    217         }
    218 
    219         return pc;
    220 }

What does "thread_saved_pc(&p->thread);" return ? Does it really
return the exact address of the schedule functions as assumed in
205-214 ?

Most other architectures search the stack page for the calling function
but it seems their asmlinkage is more strict in the means of 
location of the return address on the stack.

The current implementation is buggy not only in the means of 
the printk but also in the wchan - Most of the output
is "schedule" itself which means none of the statements above
had been true but when extending the printk with the pc
it never exactly matches &schedule so a == schedule wont help.

Flo
-- 
Florian Lohoff		[email-masked]		      	+49-subject-2-change
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 21 Apr 2000 14:28:07 -0700

> return the exact address of the schedule functions as assumed in

It's supposed to return the address at which a currently non-executing
process will continue it's execution.

> location of the return address on the stack.

Yep, unwinding MIPS stackframes is not possible for the general case unless
you use debug information.  We don't want that, so have to use an
alternative solution that is fairly fragile and you're observing yet another
case of this.

Fixing ...

  Ralf