Wenji Huang wrote:
Hi,
When I tried the latest utrace patch to 2.6.25-rc6, found there is one
regression about waitid.
It passed in upstream kernel, but hang in utrace-patched kernel. The
test case was old one and carried
in previous kernel test. Roland once fixed the problem in
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.23.8.
It seems the second wait makes the kernel enter into infinite loop.
I did some analysis of outrace kernel according to this test case.
Parent's waitid is in such call tree:
do_wait -> do_wait_thread -> ptrace_do_wait
In fact, wait_consider_task is called first, but return 0, so need to do
ptrace_do_wait.
Piece of ptrace_do_wait code:
--------------------------------------------------------
exit_code = xchg(&p->exit_code, 0);
if (exit_code & PTRACE_TRAPPED_MASK)
goto found;
/************/
if (p->state == TASK_STOPPED)
goto found;
---------------------------------------------------------
First waittid:
child's state == TASK_TRACED, exit_code !=0, goto found, return
child's pid
Second waitid:
child's state == TASK_TRACED, exit_code ==0, continue next parts,
return 0.
That means ptrace_do_wait blocking. Only Ctrl+C to make it exit.
But the kernel doesn't hang, just parent's do_wait is blocked. It's
different from upstream kernel.
I'm not sure which behavior is correct.
Best regards,
Wenji
