Skip to contentSkip to conversation

futex_find_get_task: remove an obscure EXIT_ZOMBIE check

PATCH In review Oleg Nesterov 3 participants 7 messages Aug 21, 2006 – Aug 25, 2006

lore
Share & tools
lore

Oleg Nesterov

author
#0 lore raw

PATCH 1/3 futex_find_get_task: remove an obscure EXIT_ZOMBIE check

(Compile tested).

futex_find_get_task:

	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;

I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a long time), but this doesn't mean we should explicitely ignore other EXIT_XXX states.

Signed-off-by Oleg Nesterov <[email protected]>
kernel/futex.c renamed from kernel/futex.c~1_zomb +1 -1
@@ -397,7 +397,7 @@ static struct task_struct * futex_find_g
 		p = NULL;
 		goto out_unlock;
 	}
-	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE) {
+	if (p->exit_state != 0) {
 		p = NULL;
 		goto out_unlock;
 	}
#1 lore raw
Quoted 7 lines · Oleg Nesterov

(Compile tested).

futex_find_get_task:

	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;
Quoted 6 lines

I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a long time), but this doesn't mean we should explicitely ignore other EXIT_XXX states.

The p->state variable for EXIT_ZOMBIE is only live for some mystery architecture in arch/xtensa/kernel/ptrace.c

It could be a typo under architecture so maybe it's better fixed there as well with a "state" to "exit_state" change. I don't really know for sure since I don't work under that architecure.

bill

author
#2 lore raw
Quoted 16 lines · Bill Huey
Quoted 7 lines · Oleg Nesterov

(Compile tested).

futex_find_get_task:

	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;
Quoted 6 lines

I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a long time), but this doesn't mean we should explicitely ignore other EXIT_XXX states.

Quoted 2 lines

The p->state variable for EXIT_ZOMBIE is only live for some mystery architecture in arch/xtensa/kernel/ptrace.c

Thanks. This

	case PTRACE_KILL:
		ret = 0;
		if (child->state == EXIT_ZOMBIE)	/* already dead */
			break;

is an obvious bug, I beleive. May I suggest you to make a patch?

Oleg.

#3 lore raw
Quoted 19 lines · Oleg Nesterov
Quoted 15 lines · Bill Huey
Quoted 7 lines · Oleg Nesterov

(Compile tested).

futex_find_get_task:

	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;
Quoted 6 lines

I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a long time), but this doesn't mean we should explicitely ignore other EXIT_XXX states.

Quoted 2 lines

The p->state variable for EXIT_ZOMBIE is only live for some mystery architecture in arch/xtensa/kernel/ptrace.c

Quoted 8 lines

Thanks. This

	case PTRACE_KILL:
		ret = 0;
		if (child->state == EXIT_ZOMBIE)	/* already dead */
			break;

is an obvious bug, I beleive. May I suggest you to make a patch?

Oleg,

Here is it. Maintainers CCed...

bill

#

# old_revision [d374cc860b7089468eb87b56425bb462a955b138]
# 
# patch "arch/xtensa/kernel/ptrace.c"
#  from [4ae4da59c97b72d41f6d2b38ef83f33ee8e5e3e3]
#    to [6be23f16368960b0da9f77911406e7c495396001]
# 
============================================================
--- arch/xtensa/kernel/ptrace.c	4ae4da59c97b72d41f6d2b38ef83f33ee8e5e3e3
+++ arch/xtensa/kernel/ptrace.c	6be23f16368960b0da9f77911406e7c495396001
@@ -212,7 +212,7 @@
 	 */
 	case PTRACE_KILL:
 		ret = 0;
-		if (child->state == EXIT_ZOMBIE)	/* already dead */
+		if (child->exit_state == EXIT_ZOMBIE)	/* already dead */
 			break;
 		child->exit_code = SIGKILL;
 		child->ptrace &= ~PT_SINGLESTEP;
Acked-by on v1 1/3
#4 lore raw
In reply to Oleg Nesterov
Quoted 7 lines · Oleg Nesterov

(Compile tested).

futex_find_get_task:

	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;
Quoted 8 lines

I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a long time), but this doesn't mean we should explicitely ignore other EXIT_XXX states.

Signed-off-by Oleg Nesterov <[email protected]>

i believe this is a remnant of older times when EXIT_ZOMBIE was introduced. We cloned that into the -rt tree, but then exit-state got cleaned up (by you) upstream and that cleanup didnt propagate into the -rt tree. Andrew: i think this is a must-have fix for v2.6.18.

Acked-by Ingo Molnar <[email protected]>

Ingo

author
#5 lore raw
Quoted 17 lines · Ingo Molnar
Quoted 14 lines · Oleg Nesterov

(Compile tested).

futex_find_get_task:

	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;

I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a long time), but this doesn't mean we should explicitely ignore other EXIT_XXX states.

Quoted 5 lines
Quoted 1 line
Signed-off-by Oleg Nesterov <[email protected]>

i believe this is a remnant of older times when EXIT_ZOMBIE was introduced. We cloned that into the -rt tree, but then exit-state got cleaned up (by you)

No, no, it was Roland.

But probably you are talking about these patches

	http://marc.theaimsgroup.com/?t=113284375800003&r=1
	http://marc.theaimsgroup.com/?t=113284375800005&r=1

? It was abandoned by Linus. It is not clear was he convinced or not, but I'd be happy to re-send this patch (on weekend) if you wish.

Oleg.

#6 lore raw
Quoted 7 lines · Oleg Nesterov

But probably you are talking about these patches

	http://marc.theaimsgroup.com/?t=113284375800003&r=1
	http://marc.theaimsgroup.com/?t=113284375800005&r=1

? It was abandoned by Linus. It is not clear was he convinced or not, but I'd be happy to re-send this patch (on weekend) if you wish.

sure, please do. I'm not sure how and why they were dropped - it's the author (you) who is supposed to push it! :-) (Sometimes patches can drop out of -mm due to logistical clashes or due to bugs - just re-merge / fix them in that case.) These patches certainly make alot of sense.

Ingo