There is a couple of subtle checks which were needed to handle ptracing from
the same thread group. This was deprecated a long ago, imho this code just
complicates the understanding.
And, the "->parent->signal->flags & SIGNAL_GROUP_EXIT" check in exit_notify()
is not right. SIGNAL_GROUP_EXIT can mean exec(), not exit_group(). This means
ptracer can lose a ptraced zombie on exec(). Minor problem, but still the bug.
Signed-off-by: Oleg Nesterov <[email protected]>
--- t/kernel/exit.c~PT_TG 2007-08-03 18:05:52.000000000 +0400
+++ t/kernel/exit.c 2007-08-03 21:10:40.000000000 +0400
@@ -802,7 +802,7 @@ static void exit_notify(struct task_stru
__kill_pgrp_info(SIGCONT, SEND_SIG_PRIV, pgrp);
}
- /* Let father know we died
+ /* Let father know we died
*
* Thread signals are configurable, but you aren't going to use
* that to send signals to arbitary processes.
@@ -815,9 +815,7 @@ static void exit_notify(struct task_stru
* If our self_exec id doesn't match our parent_exec_id then
* we have changed execution domain as these two values started
* the same after a fork.
- *
*/
-
if (tsk->exit_signal != SIGCHLD && tsk->exit_signal != -1 &&
( tsk->parent_exec_id != t->self_exec_id ||
tsk->self_exec_id != tsk->parent_exec_id)
@@ -837,9 +835,7 @@ static void exit_notify(struct task_stru
}
state = EXIT_ZOMBIE;
- if (tsk->exit_signal == -1 &&
- (likely(tsk->ptrace == 0) ||
- unlikely(tsk->parent->signal->flags & SIGNAL_GROUP_EXIT)))
+ if (tsk->exit_signal == -1 && likely(!tsk->ptrace))
state = EXIT_DEAD;
tsk->exit_state = state;
--- t/kernel/signal.c~PT_TG 2007-07-28 16:58:17.000000000 +0400
+++ t/kernel/signal.c 2007-08-03 21:11:59.000000000 +0400
@@ -1561,10 +1561,6 @@ static inline int may_ptrace_stop(void)
(current->ptrace & PT_ATTACHED)))
return 0;
- if (unlikely(current->signal == current->parent->signal) &&
- unlikely(current->signal->flags & SIGNAL_GROUP_EXIT))
- return 0;
-
/*
* Are we in the middle of do_coredump?
* If so and our tracer is also part of the coredump stopping
> There is a couple of subtle checks which were needed to handle ptracing from
> the same thread group. This was deprecated a long ago, imho this code just
> complicates the understanding.
Looks ok to me.
> And, the "->parent->signal->flags & SIGNAL_GROUP_EXIT" check in exit_notify()
> is not right. SIGNAL_GROUP_EXIT can mean exec(), not exit_group(). This means
> ptracer can lose a ptraced zombie on exec(). Minor problem, but still the bug.
This bug never happens because this check is only in the now-impossible
ptrace-same-group case. The code can certainly go.
Thanks,
Roland
On 08/03, Roland McGrath wrote:
>
> > There is a couple of subtle checks which were needed to handle ptracing from
> > the same thread group. This was deprecated a long ago, imho this code just
> > complicates the understanding.
>
> Looks ok to me.
Thanks!
> > And, the "->parent->signal->flags & SIGNAL_GROUP_EXIT" check in exit_notify()
> > is not right. SIGNAL_GROUP_EXIT can mean exec(), not exit_group(). This means
> > ptracer can lose a ptraced zombie on exec(). Minor problem, but still the bug.
>
> This bug never happens because this check is only in the now-impossible
> ptrace-same-group case.
This means that changelog is wrong and should be changed.
However, I disagree. exit_notify() doesn't check the ptrace-same-group case. So,
unless I missed something, we set EXIT_DEAD in any case, even if ptracer doesn't
belong to our thread group.
No?
Oleg.
> However, I disagree. exit_notify() doesn't check the ptrace-same-group
> case. So, unless I missed something, we set EXIT_DEAD in any case, even
> if ptracer doesn't belong to our thread group.
Oh, you're right. I was reading the other line you changed.
Thanks,
Roland