Oleg Nesterov <[EMAIL PROTECTED]> writes: > On 12/08, Eric W. Biederman wrote: >> >> Oleg Nesterov <[EMAIL PROTECTED]> writes: >> >> > p->exit_state != 0 doesn't mean this process is dead, it may have > sub-threads. >> > >> > However, the new "p->exit_state && thread_group_empty(p)" check is not > correct >> > either, this is just the temporary hack. Perhaps we can just remove this > check, >> > but I don't understand orphaned process groups magic. At all. However, I > think >> > exit_notify() is obviously and completely wrong wrt this helper. >> >> The problem that orphaned processes groups address is what happens if >> an entire process group is stopped, and there is not a process that >> can wake them up. >> >> The rule for an unprivileged process sending a signal to a process >> group is that it must be in the same session as the process group. >> >> The rule for sending a signal to a process group is that the signal sender >> must be in the same session. >> >> So we are testing for a process group that does not have a living >> member with a parent outside of the process that can send the process >> group a signal. > > Ah, thanks a lot Eric, I am _starting_ to understand this. > >> Oleg what do you see wrong with checking p->exit_state && >> thread_group_empty(p)? Since non-leader threads all self reap >> that seems to be a valid test for an dead thread group. > > There is a window when exit_notify() drops tasklist and before release_task(). > Suppose the last (non-leader) thread exits. This means that entire group > exits, > but thread_group_empty() is not true.
And if you are an observer this is important. Equally messed up is a our status in /proc at that point. Which says our sleeping process is a zombie. I'm thinking we need to do at least some of the thread group leadership transfer in do_exit, instead of de_thread. Then p->group_leader->exit_state would be sufficient to see if the entire thread group was alive, as the group_leader would be whoever was left alive. The original group_leader might still need to be kept around for it's pid... I think that would solve most of the problems you have with a dead thread group leader and sending SIG_STOP as well. Eric -- 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/