Make sure that the new debugger doesn't get the old values in ptrace_context or engine->flags if it re-uses the self-detaching engine.
In particular, we should clear tracee->exit_code. The new debugger should not see it via do_wait() until the tracee stops again. This is racy, but ->exit_code changes were always racy in ptrace. Hopefully sooner or later ptrace will not use ->exit_code at all. Perhaps we should move this reinitialization into ptrace_attach_task(), we will see. Perhaps, instead of utrace_control() ptrace_detach_task() should use ptrace_wake_up() which clears SIGNAL_STOP_STOPPED. This is wrong, but more compatible with the current implementation. I dunno. --- kernel/ptrace.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- PU/kernel/ptrace.c~82_RESET_CONTEXT_ON_DETACH 2009-10-10 17:13:37.000000000 +0200 +++ PU/kernel/ptrace.c 2009-10-10 17:43:28.000000000 +0200 @@ -109,7 +109,16 @@ static void ptrace_detach_task(struct ta case PTRACE_EVENT_SIGNAL: if (valid_signal(sig)) context->signr = sig; + context->options = 0; + context->eventmsg = 0; context->stop_code = 0; + /* make sure do_wait() can't succeed */ + tracee->exit_code = 0; + utrace_set_events(tracee, engine, UTRACE_EVENT(QUIESCE)); + /* + * once we set UTRACE_DETACH we don't own this engine, + * utrace_set_events() also acts as a memory barrier. + */ context->resume = UTRACE_DETACH; action = UTRACE_RESUME; break;