the attached patch fixes one bug in the way we did zap_thread() - but this
alone does not fix the lockup.
the bug was that list_for_each_safe() is not 'safe enough' - zap_thread()
drops the tasklist lock at which point anything might happen to the child
list.
the lockup is likely in the while loop - ie. zap_thread() not actually
reparenting a thread and thus causing an infinite loop - is that possible?
Ingo
--- linux/kernel/exit.c.orig Mon Sep 9 21:59:24 2002
+++ linux/kernel/exit.c Mon Sep 9 22:24:41 2002
@@ -493,7 +493,6 @@
static void exit_notify(void)
{
struct task_struct *t;
- struct list_head *_p, *_n;
forget_original_parent(current);
/*
@@ -554,17 +553,16 @@
do_notify_parent(current, current->exit_signal);
zap_again:
- list_for_each_safe(_p, _n, ¤t->children)
- zap_thread(list_entry(_p,struct task_struct,sibling), current, 0);
- list_for_each_safe(_p, _n, ¤t->ptrace_children)
- zap_thread(list_entry(_p,struct task_struct,ptrace_list), current, 1);
+ while (!list_empty(¤t->children))
+ zap_thread(list_entry(current->children.next,struct task_struct,sibling), current, 0);
+ while (!list_empty(¤t->ptrace_children))
+ zap_thread(list_entry(current->ptrace_children.next,struct task_struct,sibling), current, 0);
/*
* zap_thread might drop the tasklist lock, thus we could
* have new children queued back from the ptrace list into the
* child list:
*/
- if (unlikely(!list_empty(¤t->children) ||
- !list_empty(¤t->ptrace_children)))
+ if (unlikely(!list_empty(¤t->children)))
goto zap_again;
/*
* No need to unlock IRQs, we'll schedule() immediately
-
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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:18 EST