On 04/27, Oleg Nesterov wrote: > > 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...
On the other hand, I don't understand why did you move the callsite of do_notify_parent_cldstop() up... just don't do this? Oleg. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
