On 04/11, Bill Davidsen wrote: > > Oleg Nesterov wrote: > >On 04/10, Eric W. Biederman wrote: > > > >>I'm trying to remember what the story is now. There is a nasty > >>race somewhere with reparenting, a threaded parent setting SIGCHLD to > >>SIGIGN, and non-default signals that results in an zombie that no one > >>can wait for and reap. It requires being reparented twice to trigger. > > > >reparent_thread: > > > > ... > > > > /* If we'd notified the old parent about this child's death, > > * also notify the new parent. > > */ > > if (!traced && p->exit_state == EXIT_ZOMBIE && > > p->exit_signal != -1 && thread_group_empty(p)) > > do_notify_parent(p, p->exit_signal); > > > >We notified /sbin/init. If it ignores SIGCHLD, we should release the task. > >We don't do this. > > > >The best fix I believe is to cleanup the > >forget_original_parent/reparent_thread > >interaction and factor out this "exit_state == EXIT_ZOMBIE && exit_signal > >== -1" > >checks. > > > As long as the original parent is preserved for getppid(). There are > programs out there which communicate between the parent and child with > signals, and if the original parent dies, it undesirable to have the > child getppid() and start sending signals to a program not expecting > them. Invites undefined behavior.
Sorry, can't understand. If p->exit_signal == -1 after do_notify_parent() above, the task is completely dead. Nobody can release it, we should do this (if EXIT_ZOMBIE). At this point "p" was already re-parented, but this (and getppid) doesn't matter at all. OK. Most likely you meant something else. Could you 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/
