On 04/26, Eric W. Biederman wrote: > > @@ -2209,6 +2213,34 @@ static int ptrace_stop(int exit_code, int why, int > clear_code, > spin_lock_irq(¤t->sighand->siglock); > } > > + /* Don't stop if current is not ptraced */ > + if (unlikely(!current->ptrace)) > + return (clear_code) ? 0 : exit_code; > + > + /* > + * If @why is CLD_STOPPED, we're trapping to participate in a group > + * stop. Do the bookkeeping. Note that if SIGCONT was delievered > + * across siglock relocks since INTERRUPT was scheduled, PENDING > + * could be clear now. We act as if SIGCONT is received after > + * TASK_TRACED is entered - ignore it. > + */ > + if (why == CLD_STOPPED && (current->jobctl & JOBCTL_STOP_PENDING)) > + gstop_done = task_participate_group_stop(current); > + > + /* > + * Notify parents of the stop. > + * > + * While ptraced, there are two parents - the ptracer and > + * the real_parent of the group_leader. The ptracer should > + * know about every stop while the real parent is only > + * interested in the completion of group stop. The states > + * for the two don't interact with each other. Notify > + * separately unless they're gonna be duplicates. > + */ > + do_notify_parent_cldstop(current, true, why); > + if (gstop_done && ptrace_reparented(current)) > + do_notify_parent_cldstop(current, false, why);
This doesn't look right too. The parent should be notified only after we set __state = TASK_TRACED and ->exit code. Suppose that debugger sleeps in do_wait(). do_notify_parent_cldstop() wakes it up, debugger calls wait_task_stopped() and then it will sleep again, task_stopped_code() returns 0. This can be probably fixed if you remove the lockless (fast path) task_stopped_code() check in wait_task_stopped(), but this is not nice performance-wise... Oleg. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
