On 12/08, Eric W. Biederman wrote: > > Oleg Nesterov <[EMAIL PROTECTED]> writes: > > > ptrace_stop() decrements ->group_stop_count to "participate" in group stop. > > This looks very wrong to me, the task can in fact decrement this counter > > twice. > > If the tracee returns to the user-space before other threads complete the > > group > > stop, it will notice TIF_SIGPENDING and do it again. > > This is one of those interesting weird cases. The ptrace interface remains > per > task. > > So need to handle a simultaneous thread group stop and a per task stop. > > > > > > Another problem is that we don't set SIGNAL_STOP_STOPPED if the counter > > becomes > > zero. > > > > I must admit, I don't undestand the reason why this code was added, it is > > very > > old. > > I haven't dug in enough yet to understand better, but it is my hunch we > need to do something when we have both kinds of stop happening simultaneously.
Looking further, I think it was done to match the !is_task_stopped_or_traced() check in do_signal_stop(). Still, I don't understand why we really need this decrement. The ptrace interface needs only per-thread TASK_TRACED ot TASK_STOPPED, it doesn't need the completion of the group stop. We can delay the completion of the group stop, but why this is bad? At worse, the tracer recieves the extra CLD_STOPPED when the tracee resumes. And do_signal_stop() probably can s/is_task_stopped_or_traced/is_task_stopped/. OK, it is better to ignore this patch, I don't understand all implications of this change. But this all doesn't look very good. Suppose we have a lot of threads and the task with _TIF_SYSCALL_TRACE does system call. So ptrace_notify() decrements the counter before syscall, after, and before the return to user-space. Hopefully Roland can clarify. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
