[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20060826191817.GA173@oleg>
Date: Sat, 26 Aug 2006 23:18:17 +0400
From: Oleg Nesterov <oleg@...sign.ru>
To: Ingo Molnar <mingo@...e.hu>
Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: [PATCH 3/3] introduce TASK_DEAD state
I am not sure about this patch, I am asking Ingo to take a decision.
task_struct->state == EXIT_DEAD is a very special case, to avoid a confusion
it makes sense to introduce a new state, TASK_DEAD, while EXIT_DEAD should
live only in ->exit_state as documented in sched.h.
Note that this state is not visible to user-space, get_task_state() masks
off unsuitable states.
Signed-off-by: Oleg Nesterov <oleg@...sign.ru>
--- 2.6.18-rc4/include/linux/sched.h~3_rename 2006-08-26 21:28:54.000000000 +0400
+++ 2.6.18-rc4/include/linux/sched.h 2006-08-26 23:03:44.000000000 +0400
@@ -148,6 +148,7 @@ extern unsigned long weighted_cpuload(co
#define EXIT_DEAD 32
/* in tsk->state again */
#define TASK_NONINTERACTIVE 64
+#define TASK_DEAD 128
#define __set_task_state(tsk, state_value) \
do { (tsk)->state = (state_value); } while (0)
--- 2.6.18-rc4/kernel/exit.c~3_rename 2006-08-26 21:46:45.000000000 +0400
+++ 2.6.18-rc4/kernel/exit.c 2006-08-26 22:31:50.000000000 +0400
@@ -955,7 +955,7 @@ fastcall NORET_TYPE void do_exit(long co
preempt_disable();
/* causes final put_task_struct in finish_task_switch(). */
- tsk->state = EXIT_DEAD;
+ tsk->state = TASK_DEAD;
schedule();
BUG();
--- 2.6.18-rc4/kernel/sched.c~3_rename 2006-08-26 21:56:46.000000000 +0400
+++ 2.6.18-rc4/kernel/sched.c 2006-08-26 22:37:48.000000000 +0400
@@ -1751,10 +1751,10 @@ static inline void finish_task_switch(st
/*
* A task struct has one reference for the use as "current".
- * If a task dies, then it sets EXIT_DEAD in tsk->state and calls
+ * If a task dies, then it sets TASK_DEAD in tsk->state and calls
* schedule one last time. The schedule call will never return, and
* the scheduled task must drop that reference.
- * The test for EXIT_DEAD must occur while the runqueue locks are
+ * The test for TASK_DEAD must occur while the runqueue locks are
* still held, otherwise prev could be scheduled on another cpu, die
* there before we look at prev->state, and then the reference would
* be dropped twice.
@@ -1765,7 +1765,7 @@ static inline void finish_task_switch(st
finish_lock_switch(rq, prev);
if (mm)
mmdrop(mm);
- if (unlikely(prev_state == EXIT_DEAD)) {
+ if (unlikely(prev_state == TASK_DEAD)) {
/*
* Remove function-return probe instances associated with this
* task and put them back on the free list.
@@ -5116,7 +5116,7 @@ static void migrate_dead(unsigned int de
BUG_ON(p->exit_state != EXIT_ZOMBIE && p->exit_state != EXIT_DEAD);
/* Cannot have done final schedule yet: would have vanished. */
- BUG_ON(p->state == EXIT_DEAD);
+ BUG_ON(p->state == TASK_DEAD);
get_task_struct(p);
--- 2.6.18-rc4/mm/oom_kill.c~3_rename 2006-08-26 21:34:04.000000000 +0400
+++ 2.6.18-rc4/mm/oom_kill.c 2006-08-26 22:34:35.000000000 +0400
@@ -206,7 +206,7 @@ static struct task_struct *select_bad_pr
*/
releasing = test_tsk_thread_flag(p, TIF_MEMDIE) ||
p->flags & PF_EXITING;
- if (releasing && (p->state != EXIT_DEAD))
+ if (releasing && (p->state != TASK_DEAD))
return ERR_PTR(-1UL);
if (p->flags & PF_SWAPOFF)
return p;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists