I think that's wrong.  When the tracer dies unceremoniously, the tracee
should continue as if it had not been traced.  Your change makes it swallow
a normal signal waiting to be delivered, and then resume as if noone had
ever sent a signal.  

There is indeed a longstanding problem for tracing-induced signals
(e.g. SIGTRAP for single-step or exec).  One can be queued but not yet
delivered while the tracer detaches or dies, and then it gets delivered
to the unsuspecting process without any debugger to intercept it.
I plan to address that eventually, but there is no quick fix for it.

In the non-signal (ptrace_notify) cases, we don't have the queuing issue.
But it's still not as simple as checking current->ptrace to decide whether
to follow current->exit_code or clear it.  When PTRACE_DETACH is called
with a parting signal (nonzero data argument), the tracee will wake up to
see current->ptrace = 0 and current->exit_code = signo and it is explicitly
intended to act on signo rather than ignore it.

The particular case you mentioned could be addressed by something like this:

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1654,6 +1654,9 @@ static void ptrace_stop(int exit_code, i
 	spin_lock_irq(&current->sighand->siglock);
 	current->last_siginfo = NULL;
 
+	if (current->exit_code & ~0x7f)
+		current->exit_code = 0;
+
 	/*
 	 * Queued signals ignored us while we were stopped for tracing.
 	 * So check for any that we should take before resuming user mode.

But that only catches the PTRACE_O_TRACESYSGOOD cases, and not bare SIGTRAP.
To be clean, there is no way to distinguish a left-over SIGTRAP that ought
to be ignored from an intentional SIGTRAP placed there by the debugger for
the tracee to deliver.  (Granted passing SIGTRAP through after a syscall is
rarely or never done.  But that doesn't make a special-case kludge right.)

I do very much appreciate the concerns that motivated your change, and share
them.  But you can see that this is a small part of a large can of worms.
It has been this way for a long time.  I am working steadily towards new
ways to clean up the entire picture.  In the meantime, I don't really favor
any marginal changes like this that complicate the behavior with more
special cases that address only a tiny corner of the whole set of problems.


Thanks,
Roland
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/